(re-posting this coz an admin had deleted this thread by mistake)
I’m testing Comodo 3.0.2.5 alpha
just clicking on “View Firewall Events” takes more than 20s to bring up the event log. and there’s huge CPU hit as well… I think it’s thanks to the brilliant performance of Access DB that’s used for logging. the log file (mdb) was just 10mb and had around 150,000 events in it.
The magic word = KISS (developers know this best).
what would a normal user want from a firewall log? to quickly see through a few past events to figure out if it is blocking his P2P app… he does not need a full DB to do data mining on it!
why not have a simple log file (like in Comodo2?), which will have the last n events/bytes? simple, lightning fast, and does the job. If u really love to have a DB, maybe add that as a option for the user to select.
also I hate when applications continuously keep reading/writing my disk - annoying!. do a batch write; log every 100 events (in batches) to the disk; (maybe flush on a timer as well)
REMEMBER: a firewall is a security tool, not a productivity application; it shouldn’t interfere with a user’s day-to-day work. (eat his CPU cycles or crunch his disk)
other than that, Comodo3 rocks! beats ZoneAlarm Pro hands down!!
This section should be only used to ask for help and the bugs section would be barely eligible for suggestions posts like that, nevertheless I’ll continue this topic considering the nature of wolfie post. 88)
It’s against common sense to hear that a database has a worst performance compared to a flat file log but since this is still an alpha I bet the developer are focusing on more important tasks.
The V3 log provides an unparalleled level of flexibitiy to users, KISS ones included.
Since this post is not a PROMO I’ll add my suggestion too to improve the log, although I’m a humble user.
My best guess is that the log list component is iteratively populated. This should be the cause behind the scrollbar cursor size decrease during log list component redraws.
From what I have heard, a more effective way to accomplish this should be generating the entire list using a separate object and then populate the list component after the list is completely built.
Another point often mentioned in the forums pertains to the number of IO accesses.
Those numbers should pose NO problem since they are generated through windows APIs.