Thanks for all the help guys! 

@lashiec : how do you suggest I use process monitor for that particular case... Just normally, with the registry, process and file activity turned on ?

@mouser : I don't think I have any other anti-whatever installed. Just Comodo and NOD32. So next step involves uninstalling NOD32, completely.

BTW, i just rechecked and farr now writes its ini in less than 2s. the strange thing is that it wasn't when I last tried, after uninstalling comodo. That's just plain weird and annoyingly incoherent (well, for my brain, at the moment).

I use NOD32 so i doubt it's that (though to be fair i have seen NOD32 do this behavior, but not on ini files).
You might just go to nod32 options and disable some optional hueristics and see if that solves it, rather than completely uninstalling.

but it would be interesting to hear if it was really comodo causing the problem with FARR.

After 2h of testing, monitoring, etc. well... NOD32 is the guilty one!!!!!!! I had deactivated it, etc. but it wasn't enough and it's only after complete uninstallation that IniReader gave me my first normal results : write : 23.2s, read : 19.5s. Now you're talking.

The weirdest whing is that the NOD32 service didn't show ANY activity or anything, even in process monitor. The stupidest thing is that I waited and waited before uninstalling it, even if I my intuition told me otherwise. 

Now WHAT.  I wonder what I can do about this NOD32 thing. Maybe I'll just reinstall it and see what happens.

Anyway... To be continued -- I have to wake up in a few hours so I shall get some sleep. Damn antiviruses and firewalls.

fascinating discovery!

as i said i actually observed nod32 doing this to be before, but only in a directory full of html files.
i personally use nod32 as my antivirus and dont notice any farr slowdown issues.. however i do have the heursistic scanning disable since i find that is unreliable.

It behaves normally when I disable Files Scan on "Open"  and "Create" (AMON-->Detection Setup -->Files - Scan On). Now, I'm not sure if that's a good idea...

yeaaaaaah! I'm not alone! 
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. 

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?

Quote from: Armando on January 18, 2008, 06:12 AM

if nod32 has that kind of impact on (read/)write operations

That isn't the problem, it only has impact on (read/)write INI operations, which isn't that anoying.

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.

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?

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.

We shall do that 

Edit : added some precisions.

BTW, lashiec : how's avast ?

Oh man.. That just proves that i have good reasons to hate antivirus software!

About adding gridmove and farr's directory to the exclusions, well.. Everyone knows that neither has viruses (and won't have in the future ). What I'm not sure about is if there are any chances of a virus that comes from other software crawling into any of those 2 dirs.

I think it might make sense to exclude all .ini from scanning.. risk is extremely low and might speed up system-wide stuff.

It's highly unlikely that a text file could be used to infect a computer, I would go as far as to say that it's impossible, considering what a text file is. If you want to be sure, ask about it in the Living Room.

How's avast? Fine, it's free . I mean, it does its work, does not get in the way, and is pretty decent for the price. Not NOD32, but a fine antivirus. Very lightweight as well, and did you know that INI operations are not affected by it?

mouser is using ESET Smart Security, BTW. I suppose the version of NOD32 used in the suite it's the same as the standalone one, but who knows. He used Comodo during a brief time, though, until not too long ago. Bad timing, I guess.

Warning to those using Comodo : if you don't want to experience slowdowns and freezes, You have to make the choice AT INSTALLATION TO NOT ACTIVATE DEFENSE+.

If you decide to deactivate it only after activating it at install, it WILL NOT work -- you'll still experience slowdowns, and you'll have to uninstall Comodo and reinstall it (and chose not to activate defense+). Weird, I know.
Same thing if you decide to ulteriorly activate Defense+ and later deactivate it again (like I just did) : if you try to deactivate after activating it, it WILL NOT cancel farr's slowdowns or freezes. It's a bit like if it would remain there, doing nothing valuable, but still slowing down everything (i tried rebooting, etc. to no avail. Only uninstalling & reinstalling works).

Summary : forget about defense+ altogether if you want to have a running farr without freezes.