Author Topic: [Bug report?] farr - short freeze every 6 launch/close (Read 68791 times)

Armando · « **on:** January 16, 2008, 05:29 PM »

Every 6 launch/close (

), farr will freeze for about 5.5 seconds (usually when launching something or just before being "closed"/hidden...). I don't know exactly when this has started, but it's been like that for a little while... probably since I changed my Launch history value to 999!

Anyway : I've discovered that the freeze corresponds to when farr saves changes to its ini file and creates a backup. Needless to say, my ini file has lots of lines... hence, it's pretty "big" (for an ini file... 69.5 Kb). But why on earth would it take so much processing power and freeze farr for a full 5.5 sec to save an ini file and create a backup?

I tried reducing the ini file's size (by cutting the "LaunchHistory" section to 30 items) : farr's 6th satanic shutdown is much quicker : there'll be a slight freeze :1-1.5 sec maybe). The devil is in the ini size, it seems -- in this case, bigger isn't better, it seems...

(PS : just in case, I also tried stopping my antivirus and firewall -- they don't seem to be guilty of anything here. ~~Maybe a "faulty" plugin? I tried deactivating them all, but it still does it. I could try reinstalling everything, but don't have enough time tonight~~ [edit : see next post].)

(computer specs : laptop, core duo 1.8ghz, 2GB RAM)

Armando · « **Reply #1 on:** January 16, 2008, 06:14 PM »

BTW - removing ALL plugins from the plugin folder didn't seem to affect the short freeze problem -- so it's not plugin related, it seems.

mouser · « **Reply #2 on:** January 16, 2008, 07:09 PM »

yeah this is due to inefficient ini saving of the history list on farr's part.. i'll put on my todo list to save history to a separate data file.

Armando · « **Reply #3 on:** January 16, 2008, 07:44 PM »

I see. Thanks!

mouser · « **Reply #4 on:** January 16, 2008, 08:28 PM »

still shouldnt be such a big delay, so im not sure its the whole answer, but clearly that's most of the problem.

jgpaiva · « **Reply #5 on:** January 17, 2008, 06:06 AM »

Armando: i find it strange that you have the exact same problem with gridmove (it taking too long to read the ini file).

Would it be possible that there's some issue with your windows instalation? Have you experimented this with other programs?

What do you think about me making a dummy program so that you can compare your ini reading times with other's computers?

mouser · « **Reply #6 on:** January 17, 2008, 06:07 AM »

yeah sounds like could be antivirus or another security program freaking out.

jgpaiva · « **Reply #7 on:** January 17, 2008, 06:48 AM »

Ok, i've made the test program.

On my system, it takes 45seconds to create the file, and 37 to read it. (it's a 10000 entry ini, with 173kb).

All you have to do is run the attached file once to create the .ini file, and once to read it. It'll also display the time it took to run.

(i'd also be interested in other people's numbers, so if anyone could try it too..)

[edit] corrected file size [/edit]

Lashiec · « **Reply #8 on:** January 17, 2008, 08:27 AM »

Sure, let me try my hand at it. João, it could be a good idea to post the basic specs of your computer.

23 secons to create the file, 18 to read it. avast! tray icon isn't spinning, except when the program is launched. With Windows Defender deactivated, 18 seconds to create the file, and 22-24 to read it (weird). I deactivated avast! later, but the results are the same. Tip: Use Windows Defender to speed up file copies

Machine specs: AthlonX2 5200, 2 GB RAM @ 667 MHz, Seagate 7200.10 320 GB

jgpaiva · « **Reply #9 on:** January 17, 2008, 11:46 AM »

Tip: Use Windows Defender to speed up file copies
-Lashiec (January 17, 2008, 08:27 AM)

LoL...

Thanks lashiec!

Armando · « **Reply #10 on:** January 17, 2008, 02:08 PM »

Hummm. Nice deduction jpaiva. I wouldn't be surprised too if both problems are related.

I'll run your script and see...

Armando · « **Reply #11 on:** January 17, 2008, 02:12 PM »

BTW : when I was testing farr's freeze, I disabled antivirus + firewall + a bunch of other things.... So I don't think it was that.

Anyway, I'll see

(PS : just in case, I also tried stopping my antivirus and firewall -- they don't seem to be guilty of anything here.
-Armando (January 16, 2008, 05:29 PM)

Armando · « **Reply #12 on:** January 17, 2008, 06:04 PM »

write : 743.32 sec
read : 28.6 sec

(computer specs : laptop, core duo 1.8ghz, 2GB RAM)

Pretty bad. So somethings really wrong. I Tried disabling Comodo completely, shut down my antivirus. Nothing. I even suspected my ram. Removed a stick, etc. Nothing.

Next step : uninstall comodo completely and see what happens.

Does somebody know why it could be writing so sllllooooowwwly (eating a lot of CPU power) but reading normally (although slower than lashiec...

) ????

jgpaiva · « **Reply #13 on:** January 17, 2008, 06:14 PM »

Ok, so that explains the problem with farr. Curiously, it doesn't explain the problem with gridmove, as it only READS in the section that causes you problems, and the read times you posted look pretty average.

Regarding the fix for the slow read times, maybe you should open a new thread?

Have you noticed other programs taking too long to write files? How about moving stuff from that disk to another and back?

Lashiec · « **Reply #14 on:** January 17, 2008, 07:18 PM »

12 f****** minutes to write that file?! Something is really wrong there.

Armando · « **Reply #15 on:** January 17, 2008, 07:31 PM »

I forgot to mention that the peaking process (35-39%) during the (ini) file writing phase (using your script, jgpaiva) is the system.exe process. I don't know if that gives any clues...

Ok, so that explains the problem with farr. Curiously, it doesn't explain the problem with gridmove, as it only READS in the section that causes you problems, and the read times you posted look pretty average.
-jgpaiva (January 17, 2008, 06:14 PM)

i know, strange.

Regarding the fix for the slow read times, maybe you should open a new thread?
-jgpaiva (January 17, 2008, 06:14 PM)

You mean... a thread about my problem with GridMove ini file, or in general?

BTW, I just tried reloading, closing, rerunning, etc. GridMove, and the problem is pretty much GONE (or at least, attenuated) : the process reaches 33% for about 1sec and the whole initialisation takes about 3-4s, which seems pretty acceptable (compared to my previous 1.5 min). But maybe is it not optimal, compared to somebody else's computer

I suspect part of the problem was Comodo's (v3) fault, since I've now uninstalled it completely -- unfortunately, at that point comodo's guilt is a mere hypothesis. To verify and legitimate my allegations, I'd have to reinstall Comodo and see what happens (I'll do that later).

But farr still stalls for 6s.

Have you noticed other programs taking too long to write files? How about moving stuff from that disk to another and back?
-jgpaiva (January 17, 2008, 06:14 PM)

Not really... But then, I probably just didn't notice -- I'm usually pretty attentive though.

OK :

- copying a 90Mb file from one partition to another takes about 4sec.

- copying a 846mb directory (with 12 big archives and 9 different folders inside) from one partition to another takes 48s

- copying 2x900mb image file from my external usb drive to my internal HD : 33s for 1st file, 37s for 2nd one.

- saving an 8mb Word file from scratch is 1-2s.

- copying a 600 pages Word document (445 505 words, 8mb) to the clipboard takes about 3-4s. Pasting it back in a new Word document takes about 4s too. Saving the document to the hard drive takes less than 2s.

These numbers seem pretty normal to me... Aren't they ??

What else could I try?

Uninstall NOD32 ???

Armando · « **Reply #16 on:** January 17, 2008, 07:33 PM »

12 f****** minutes to write that file?! Something is really wrong there.
-Lashiec (January 17, 2008, 07:18 PM)

No kidding.

(edited my previous post)

Lashiec · « **Reply #17 on:** January 17, 2008, 07:39 PM »

Perhaps it would be a good idea to run Process Monitor while you run João's program?

Armando · « **Reply #18 on:** January 17, 2008, 07:43 PM »

Perhaps it would be a good idea to run Process Monitor while you run João's program?
-Lashiec (January 17, 2008, 07:39 PM)

Well, I did : cpu usage for system.exe varies between 35% and 39% [edit : for the whole writing phase]

BTW, new figures after uninstalling comodo :

write : 717.17 sec.
read : 21.12 sec

So uninstalling comodo seems like it did something (-7s for reading!!!). But not enough for the writing part...

Lashiec · « **Reply #19 on:** January 17, 2008, 07:53 PM »

No, I mean Process Monitor to see what the system is doing during the process: which programs are working and what are they doing, how is the file being read (for the figures, it seems like the file is being read in 1-byte chunks every second

), etc.

jgpaiva · « **Reply #20 on:** January 17, 2008, 07:54 PM »

Oh, those 3 seconds are perfectly normal.
As are those copy/move numbers.

Regarding the fact that the process with the most usage is the System process, that's normal, since the program uses the system call for reading ini files.

I meant opening a thread about your computer taking too long for writing ini files, as i've never seen anything like that

Armando · « **Reply #21 on:** January 17, 2008, 08:01 PM »

ooohhhh. Sorry lashiec. I (mis)understood "task manager".
Ok, yes, I'll do that, since process explorer or windows' task manager don't say much (or enough) in that context.

@jgpaiva : you said the ini file created by IniReader was supposed to be 127kb. Mine is 173kb.

(And : yes, I might just create another thread...)

jgpaiva · « **Reply #22 on:** January 17, 2008, 08:08 PM »

Oops, that was my error. It's 173kb here also.

Lashiec · « **Reply #23 on:** January 17, 2008, 08:19 PM »

Be warned: Process Monitor creates HUGE logs, you might need some time to go through to it, and to understand what's happening.

mouser · « **Reply #24 on:** January 17, 2008, 08:23 PM »

ive had this kind of insane behavior before from an antivirus.. and you are right to not assume that "disabling" will for sure answer the question about whether it is to blame. and definitely see if you have any other anti-trojan or anti spyware resident detection software that could be doing this.