Fantastic app - idea for faster searching

[justice]

Fantastic app, can't live without! One suggestion, could it be possible to speed up searching by caching a list of 'found results', load that in instantly, then check it for changes in the background? That way you'd get instant results with a small chance of them not existing anymore, while the list is updated when you're idling.

As i've set up FARR to go through Program Files it now takes a second or two to go through everything, so any performance improvement would be welcome!

edit: sorry nevermind i must be the million-th person to suggest this! my apologies.

[mouser]

it's ok it helps to know more people want this..
while you are waiting please keep in mind that farr *does* cache apps you actually launch from inside it, so finding an app again after you launch it once will be super fast.

[nontroppo]

But FARR still drives lots of disk access - current version causes about ~1800 I/O operations when loading the history before searching anything (I assume mostly reading icon info). Interestingly if I then type in something "pr", reset process monitor to count only new file I/O, then delete my search to go back the history list, FARR performs about ~1800 I/O operations again. It doesn't seem to cache what it pulled up originally on first load - it has to go to disk to refetch the icon data. In this case Farr should cache the data in memory so it doesn't need to go to disk.

[mouser]

nontroppo i am engaged in a prolonged tear of work on farr this last week;
folder searching and adaptive history are mostly done (testing folder searching now and tweaking it).

so if you dont let me forget i will try to tackle these too.

but do keep in mind that i'm not building an index yet so its natural that there is going to be some disk access.

i think it is also imp to remember, as far as i understand it, that the disk io you see in a process monitor doesnt really tell you if these reads are occuring physically on the disk vs. being cached by windows or even hard disk cache.  so it can be quite misleading to look at that number as actual physical disk activity (someone correct me if i'm wrong).  Indeed one of my motivations for resisting building my own index is that the operating system has its own caches/indices (thats why the second time you search after a long delay is much faster than first time).

however i suspect there is probably some unnesc. acccess when loading history, etc., that we can still improve.

[nontroppo]

OK, interesting point - do you know how to tell if I/O is to disk or not? I'd always assumed it was the difference between read / write / other (being cache hits etc) but I'm not sure.