Feature Request v2 - Speeding up searches?

[mouser]

this may not make it into version 2, it's just something to consider and plan for and discuss.

the desktop search tools like google and msn, which search INSIDE of files, work by scanning and reading files in the background (or on demand), and creating a huge database of file contents.

it is this database that is searched then when you run a search.

now i considered having F&R create a database of files and search that..
however my initial feeling was that there would be little payoff from it..
because the operating system should be fairly efficient at cacheing directory listings
and because f&r doesnt search file contents, only file names (though we could debate this)
and because f&r needs to be able to search partial words and arbitrary patterns, which makes it hard to do efficient database lookups.

so, it may simply be that there is no real way to substantially speedup searching, and that implementing a database system and background scanning is more trouble than its worth.. but it's something to consider.

the one thing that f&r does do it is take pains to store any previously launched program in a list and search that first, so the first time you search for "microsoft word" it might take several seconds to locate, but the next time it should instantaneous.  that feature could probably be enhanced to be more clever about what it caches..

any other suggestions are welcome

[kfitting]

This is different than the post above, but it has to do with speeding up searches.  mouser, do you currently check folders twice?  For example, if I have a folder entry of  C:\Misc\Mine, and then further down the list I have C:\Misc, does FindRun search \Mine again?  I was thinking about putting C:\ as my last folder entry, but it would be slow if it searched directories it's already looked in.  (that way, if the file I'm thinking of is in a different folder, I can still find it!) 

Kevin

[mouser]

yeah, currently it will search it twice if its the subset of another folder; windows internal cacheing makes this happen quite fast though.  but it would be nice to avoid that.

[nontroppo]

My holy-grail of App / File Launchers, QuickSilver for OSX, uses a database and background in-file search to data mine. Plugins can extend the search capabilities, and then hook in many contextual actions specific to these file types. This is amazingly powerful, but also complex to program (though the excellent user interface of QuickSilver hides this complexity from the user). Certainly for V2.x it seems too big a jump, but it is worth envisaging for V3+

[mouser]

i was thinking along the same lines -
let's get all of the main features we want into version 2 now
then we can think about version 3 having database and plugins.