if nod32 has that kind of impact on (read/)write operations
-Armando
That isn't the problem, it only has impact on (read/)write INI operations, which isn't that anoying.
-jgpaiva
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
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
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
We shall do that
Edit : added some precisions.