Some Performance Questions and Suggestions

[nontroppo]

On my normal laptop I never bothered with performance as FARR was snappy enough. However on an older machine with a slower HD, I notice significant delays on startup. So I used the excellent Filemon from Sysinternals to log all file activity by FARR.

On startup, FARR seems to perform a complete scan through its specified folders. This requires ~3800 open/read/writes to be performed. This seems pointless as I have it set to show the history on startup.

Then when each letter is typed, FARR rescans everything again, another 3800 file operations per letter of the incremental search.

First off, can we stop FARR from reading the folders on startup, just read its history list. Second, some kind of directory cache would drop file access a lot and speed up the incremental search. I'm not suggesting a permanent cache, only a memory cache. It may consume some extra memory, but I believe you/Windows flush memory when FARR is hidden after a launch anywayso that would not be permanent.

[mouser]

it shouldnt be performing a special scan of folders at startup until you start searching... i'll have to check that out.

as for caching searches... this gets to the whole idea of whether to use an index/database.. which we may add in a later version.
windows itself should cache directory indices which should reduce search time on incremental search - trying to add our own caching probably wouldnt do too much good.  using a real file index might though, so we should talk about this again in a bit, at least as an option at some point.. or piggybacking on another index (like google/msn/yahoo desktop search).

[kfitting]

While I do not have any hard data, I was wondering if there was any way to speed up FindRun upon hitting the pause/break key.  It seems to take a second or two, during which you cant type any search characters in.  Just wondering.... version 1.0.67.43.678.07.18 works great so far!

Kevin

edit: Actually the memory cache would be interesting... especially if it went away when FindRun was minimized.  Memory usage doesnt matter while FindRun is up and working.

[mouser]

the delay on startup seems to be windows freeing most of the memory while the program is minimized..
thus it only happens after you haven't used the program in a while (try hitting break key 10 times in a row to toggle on and off and it should be fast).

i could probably make an option that tells F&R to not give up its memory when minimized, which would make it instantaneously startup when you hit break key, but which would make it use same amount of memory when displayed as when hidden.  should i add that?

[kfitting]

What's one more option?   Heh heh, I'd be willing to give it a try if that's the cause of the slowdown.  FindRun takes 5 meg of memory while open on my machine.  I would however make the option well documented so people would not get all excited by this "low footprint" app taking up "so much" memory  (for people like me, in other words!).  But, I'd be willing to put up with some more memory usage.

Kevin

[nontroppo]

I see memory cache as being different to the database, and you can add one without adding the other (though I do realise there is overlap as far as development goes). The advantage of memory cache is that it doesn't need any of the complex monitoring / updating, all it does is cache the names on first search and uses the memory version as the next letter gets typed. I don't notice windows does much cacheing at all...

+1 to an option to stop Windows flushing the memory; you can call it TURBO mode — every program should have one!

BTW, when starting FARR, of those 3800 file operations, about 800 of them are FARR checking the skin folder, even if I am not using any skin:

17:01:44.444   FindAndRunRobot:2652   FSCTL_IS_VOLUME_MOUNTED   C:\Program Files\Farr\Skins   SUCCESS

[mouser]

i'll check the startup code and see what i see, maybe i'm doing something inefficient.

[nontroppo]

The large number of startup requests ONLY occur when launch history is shown at start; though the constant skin directory checking occurs irrespective of that setting, or resize window.

[mouser]

thanks for the clue, that will help me track it down.

[nontroppo]

I've also noticed, that if I type in something only an alias group will match, FARR still keeps scanning through the folders on every key press, so with the email thing:

email john@te

There is nothing that matches apart from the email group, yet FARR keeps scanning all directories on every new keypress. Once only aliases are left in the list, I suggest you stop incremental search. The memory cache would also fix this.

[mouser]

thats a good point..
when you match an alias name exactly it will stop searching, but when its not an exact match it keeps going..
i'm not sure how reliably i can have it figure out to stop, i'll think about it.

[lanux128]

hi there,

just noticed this topic, i want to mention that once i had this problem where suddenly my pc slowed down to a crawl. and when i started process explorer, it reported that F&RR was using up the CPU cycle (if that is the term) so i killed F&RR. when i ran F&RR once again, everything was normal...

Some Performance Questions and Suggestions

Free Image Hosting by ImageShack

maybe it was just coincidence... ;-)

best regards,
lanux

[mouser]

one thing that user fodder reported and i've confirmed is that if you have UNC shortcuts in your Recent Documents list (links to files on a remote computer via your lan), it can cause a stall in F&R as it tries to resolve the links; that will be fixed soon.

[nontroppo]

Bug tracker links relating to this:

Stop scanning on start: https://www.donation...cking/view.php?id=77
Temporary File list cache: https://www.donation...cking/view.php?id=78
Stop Scanning on Alias match: https://www.donation...cking/view.php?id=79

[mouser]

thanks nontroppo and those who are entering bugs and feature requests -
it really does make a big difference to be able to go see that list all in one place so clearly.

[kfitting]

Just wanted to resurface this discussion... I've been having problems with FARR lately while doing a lot of background tasks.  When I hit pause/break FARR takes forever to pop up (well, it's actually not 'forever!') and if I've started typing before it "initializes" some letters are typed in but not all.  Basically, I think it's the disk access slowing things up during another background disk access. 

Please take your time, I realize the other programs are getting their due attention right now.  I'm just bringing this up so it isnt forgotten and gets fixed in the next version!

Kevin

[mouser]

thanks for being understanding.  as you know from past work on f+r i tend to work in bursts on different apps, focusing on one for a few weeks or a month and then switching over to another.  f+r stuff is still percolating in my mind and it'll get it's turn at bat soon

[nontroppo]

Basically, I think it's the disk access slowing things up during another background disk access. 

-kfitting (January 15, 2006, 02:04 PM)

Do try to turn off showing history on starting (link to bug 77), that has kept me able to continue using FARR on my older machine...