I have a large directory which when searched for a file name may take 5 minutes to complete. A second search (right away) often takes 3 seconds. Why do the indexes disappear? Is there a way to keep them around?
Lots of small files? That's just the filesystem/windows caching the information.
Thanks for the fastest response. Very big directory (13gb) with 200k files.
Might I help it getting more (resources)?
This sounds like windows file system file cache. It's the same reason that when you re-read a directory it appears instant.
Select to output the results to a file collection to save the results.
(I seem to be doing the same things today as 2 years ago and having the same problems only the directories are bigger now - 300k files.)
For the last two years this problem (View/Flat View/Mixed (No Folders)) seemed to have sorta "gone away" -- first time it may take minutes (10) and the next time seconds (about 10k files a second). But often it would immediately begin the fast action without the rebuild business even between sessions.
Recently, I moved the directory to another disk (from FAT32 to NTFS) and upgraded to Vn 9 (not sure if relevant). Today it more frequently has to do the "rebuild" from scratch every time.
Do you have any new ideas around this problem? (XP)
I described a slightly different problem, but similar in my mind. This time using View/ Flat View/Mixed to count the number of files in the directory.
All Opus is doing is reading the list of files. 99.99999% of the speed is down to how quickly the OS/filesystem/hardware can build and return that list.
Unless, that is, you've got the Description column or some other field that causes Opus to open all of the files. That can obviously slow things down. It seems unlikely to be that though as it would slow things down every time instead of just sometimes.