DonationCoder.com Software > Find And Run Robot

comment on new version 1.10.02 beta

(1/2) > >>

masu:
congratulation mouser,

the new version is a huge improvement in speed  :Thmbsup:

nontroppo:
Hi mouser,

thanks for a new version!  8) I will run it as my default launcher to help fix any bugs / make improvements...

Could you explain a little at how the new cache works? There appears to be some increase in speed somehow, but there is still a lot of disk access.

I get ~1351 I/O operations on first trigger without entering any text, of which the majority are accesses to desktop.ini - this seems to be FARR getting information on each item in the history list.

I am searching for "opera" - I have only 2 directories, Ian\Start Menu (149 files including .ini's etc) All Users\Start Menu (214 files incl. ini's etc) being searched.

Typing in the first letter "o" gives ~21,000 I/O operations - some >4000 of those are to repeated reads of desktop.ini again. Another keypress "p" causes an additional ~16,000 I/O operations. Deleting a letter "p" again causes another set of ~20,000 operations, it does not seem to have cached "o" typed alone.

I have enabled the experimental cache in preferences. My version say 1.10.05.

IINM the cache is not operational in this situation?

mouser:
All the new trick does is briefly access the the cache items and the directories in the search list (not recursively), every 10 minutes, in an attempt to convince the system  to keep these directories in the operating systems own cache.  It's very primitive and just an experiment.  in my heart i've always felt the operating system should be smart enough to cache this stuff, so this is my attempt to see if i can "covince it" to do so.

I get ~1351 I/O operations on first trigger without entering any text, of which the majority are accesses to desktop.ini - this seems to be FARR getting information on each item in the history list.
--- End quote ---

this is strange - i am going to studd io operations when testing farr in the future and see if i can't see what causes what.  it really shouldn't be going through the entire history list unless something regressed in the last version (which is possible), since it not supposed to even look behind the top items on a blank search.

nontroppo:
in my heart i've always felt the operating system should be smart enough to cache this stuff, so this is my attempt to see if i can "covince it" to do so.-mouser (September 26, 2006, 07:37 AM)
--- End quote ---

well, at least on my system, this is not working. it was some time since i last profiled FARR thoroughly so whether anything here is a regression I don't know.

NeilS:
Mouser, just a thought about cacheing...

Rather than trying to coax the system to keep the relevant directories fresh in its cache, would the FindFirstChangeNotification/ReadDirectoryChangesW APIs maybe serve your overall purpose (minimising directory reads but dealing with changes) more efficiently?

FindFirstChangeNotification lets you get notifications of any changes to entire subtrees of the file system. When you get one of these notifications, ReadDirectoryChangesW lets you enumerate just the changes. If you combined this with an in-memory representation of the tree (which you probably already have?), it should be possible to achieve pretty instant results in FARR while minimising disk access.

Does this sound like a useful solution?

Navigation

[0] Message Index

[#] Next page