ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Find And Run Robot

[Bug report?] farr - short freeze every 6 launch/close

<< < (8/15) > >>

Armando:
yeaaaaaah! I'm not alone!  ;D
Actually, that's kind of sad as I was expecting you to give me the secret of perfect nod32 performance...  :)
oh well.
I don't really feel like spending more money on another antivirus, but if nod32 has that kind of impact on (read/)write operations, hummmm.... Time to re-evaluate.... again.  :( Or find a way to configure nod32 so that it behaves properly (seems improbable with v.2.x). Which version have you registered? (I going to bed now... I really have to, but I'll follow that tomorrow afternoon.)

Now I'm stuck with two problematic apps : Comodo + NOD32.  :o

jgpaiva:
I must say this is an incredible saga. While i do understand that antivirus DO slow windows activities, i never thought it might have this kind of impact.

Still, you should pay attention to something:
if nod32 has that kind of impact on (read/)write operations
-Armando (January 18, 2008, 12:12 AM)
--- End quote ---
That isn't the problem, it only has impact on (read/)write INI operations, which isn't that anoying.

Now, what i find strange is why does mouser's computer behave correctly with farr and nod32, and yours (armando), doesn't.

About comodo... I think that if it was causing delays too, maybe it has some kind of antivirus "feature" that was activated and sure wasn't needed.

lanux128:
Armando, try lurking for a while at NOD32's forums to see if there are similar complaints on this. btw, what is your PC's  memory size?

Lashiec:
And be sure to report what it seems like a bug to ESET, so they can code a fix or give some insight about what's going on.

Armando:
if nod32 has that kind of impact on (read/)write operations
-Armando (January 18, 2008, 12:12 AM)
--- End quote ---
That isn't the problem, it only has impact on (read/)write INI operations, which isn't that anoying.
-jgpaiva (January 18, 2008, 04:52 AM)
--- End quote ---

Well, hopefully. But how can we be sure about that? If I didn't have farr's growing ini file (or you script) and performance issues where I expect speed, I would've probably never noticed. Ignorance is bliss...

Now, what i find strange is why does mouser's computer behave correctly with farr and nod32, and yours (armando), doesn't.

About comodo... I think that if it was causing delays too, maybe it has some kind of antivirus "feature" that was activated and sure wasn't needed.
-jgpaiva (January 18, 2008, 04:52 AM)
--- End quote ---

first, I think we should examine how big is mouser' ini file for farr. If you remember what I wrote, the farr "freeze" got more noticeable when my ini file got bigger (hence slower to write/read) -- I earlier said  that when my my history list was cut to approximately 1/10th of its current size, the "farr-freeze" was quite small : about 2s, but nothing like 6s.

In addition, don't forget that Comodo too is/was a big slowing factor. not only Comodo tremendously affected GridMove + farr's ini file loading, but it impacted the operations of the IniReader too (writing/reading were a bit slower with Comodo than without it). Without Comodo, the ini reading/writing is quicker (MUCH quicker in farr + GridMove's case = 4-6x  faster in farr's case, 50-60x faster in GridMove's case). So NOD32 "just" added (tremendously...) to a slowdown/freeze that was already present. (And, in other words, since I don,t think mouser uses Comodo, it'S normal that he doesn't experience the same freeze)

Obviously (if you look at my earlier figures) NOD32 definitely seems to have more effect than Comodo on IniReader's read/write performance -- compared to farr or GridMove's ini read/write performance. Most probably because comodo and NOD32 don't affect the reading/writing in the same way. If I understnad well IniReader multiplies read/write operations by 10000, while in farr or GridMove's it's (I guess) only 1  read/write  operation once in a while (every 6 triggering for farr, every manual script reload for GridMove), and NOD32 is probably active analyzing the read/write process for the whole time it lasts (in IniReader the read/write takes proportionnally longer and longer  since the ini file grows byone line every cycle). Comodo might just be "affecting" the  reading/writing at the begining or end of the series of read/write... how... I don't have the slightest idea.

When I tried disabling Comodo's "defense+" features, it didn't seem to have any effect. I'll have to reinstall it though to double check.

So now I'm stuck with two problems : NOD32 + Comodo. Comodo I didn't buy, so, oh well. I might just try something else. as for NOD32, it's another story... AVAST??? Lashiec seems to get descent numbers.

Armando, try lurking for a while at NOD32's forums to see if there are similar complaints on this. btw, what is your PC's  memory size?
-lanux128 (January 18, 2008, 07:12 AM)
--- End quote ---
And be sure to report what it seems like a bug to ESET, so they can code a fix or give some insight about what's going on.
-Lashiec (January 18, 2008, 12:13 PM)
--- End quote ---


We shall do that  :)

Edit : added some precisions.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version