I am using a "File Collection" with a "Stored Query" to give me a single list of video files from multiple folders.
The Query is: ext:mp4 OR ext:avi OR ext:mpg OR ext:mkv OR ext:m4v
I currently have over 6000 files that match and pull up in the directory listing. Version 12.22 and previous versions returned the result screen in 2-3 seconds. Version 12.23 takes 2-3 minutes to do the same thing. With 12.23, I can watch the total files increment 20-30 at a time... over and over... slow slow slow
That's strange, since it's ultimately Windows Search which runs that type of query.
If you look at Task Manager, is there extra CPU or disk access while this is happening when it is slow? If so, which process is it attributed to?
Directory Opus 12.23 taking about 20% of CPU while search is going. The search is looking at two drives, both internal.
Looking at performance, I think I see the issue. The internal drive is ramping up. I can see it stepping thru the files, a second or so for each. The Read (b/sec) is ranging between 4,000,000 and 9,000,000. The "image" is dowshlp.exe. The search finished finding 6,108 file matches, total time 7 minutes 41 seconds.
I reinstalled 12.22... selected the same collection, ran in under 5 seconds... 6,108 matches. No impact on resource manager.
Did a little more testing. Created a collection "Stored Query" over windows program files and (x86). Set the query to find all bin and exe files.
Runs on each version both found 3098 matching files.
12.22 finished in 17 seconds
12.23 finished in 91 seconds.
For some reason, the speed difference is much larger on video files. It must be related to either the file size or the meta-data.
The above test is easy to duplicate.
What happens if you index the folders you're searching? Does that speed things up, or change which process is using the CPU?
(Doing an extension search using Windows Search doesn't make a lot of sense unless the folder is indexed, since you could do the non-indexed version better using the built-in Find functionality.)
My previous test was reading folders on my SSD drive.
12.22 finished in 17 seconds
12.23 finished in 91 seconds
I am running now, as in my first example, searching two hard drives. (6TB and a 10TB)
12.22 finished in 5 seconds
12.23 finished in 672 seconds (11 minutes, 12 seconds)
Both find 6124 files. This is not an index issue, as version 12.22 finishes in 5 seconds. Version 12.23 finds around 20 per each screen update... crazy.
I ran the same 'search' on FileLocator, which returns the 6124 file list in about 3 seconds.
I am afraid my use case is not common enough to merit attention. The speed of search in a larger folder on SSD is painful, but on a physical HD it's impossible.
My only saving grace is that I am able to re-install back to version 12.22.
Okay, just ran another search, this time on my "mp3" collection.
.
Using version 12.22, it found all 85,115 files in 65 seconds. The screen updates jumped 2000 and 4000 a pop.
I then installed 12.23 and ran the same collection. The screen updates ticked up often 100 per.
at the 5 minute mark it was up to 16,386 files
at the 6 minute mark it was up to 19,532 files
at the 7 minute mark it was up to 22,597 files
at the 8 minute mark it was up to 26,196 files
I quit here, I didn't need to wait 24 minutes to get the same results that version 12.22 gives me in 65 seconds.
The only thing we can think of which would affect performance between the two versions in this way relates to indexing, but we can't be sure if it's what's causing the problem you're seeing unless you try a similar search on an indexed folder to test the theory.
Okay. I indexed my video collection. Pulling up the collection in 12.23 now happens in about 2 seconds. Without indexing it took about 5 seconds.
I then started indexing my music collection to test. An hour later the search only returns 20,000 of the 85,000 files. Looks like the indexing will take another three hours. Opus 12.22 does this search in 65 seconds, without the overhead of indexing.
Then I decided to search a NETWORK drive that I don't have the indexing control of. I selected a network folder with a lot of video files and searched it with FileLocator, returning over 6000 matches in 3 minutes and 41 seconds.
I then created a new Stored Query File Collection and did the same search on both 12.22 and 12.23.
Opus 12.22 returned the same number of files, and ran only 1 minute and 59 seconds to do it.
Opus 12.23 ran for 4 minutes before I stopped it, returning 185 items... OMG
This should be easily duplicated. Opus 12.23 was updating my screen every 3-5 seconds, adding 3 items per update. At this rate it would have taking well over two hours to complete.
Opus 12.22 loaded over 3000 items in the time it took for Opus 12.23 to load 50.
Please let us know what the speed is like once it has finished indexing.
We aren't saying you have to index everything from now on. We are trying to work out what the cause of the problem is based on what happens on your machine with indexing on vs off, since we can't reproduce any issues on our own machines so far.
I just got back and indexing it complete. As a base, I did search with FileLocator which took 10 seconds. I then did the search with Opus:
with indexing
v 12.22 15 seconds
v 12.23 15 seconds
without indexing, previous test
v 12.22 65 seconds
v 12.23 480 seconds (projected)
Since you say you can not duplicate, I'll try on a different computer and report results when complete.
If you want to try something else, this is a test version of the dowshlp.exe external program that Opus uses to run non-indexed searches. It reverts a change that was made between 12.22 and 12.23. You'll need to unzip the archive and copy it over the top of the existing one in the Opus program folder (probably c:\Program Files\GPSoftware\Directory Opus).
dowshlp.zip (155.2 KB)
Please reinstall 12.23 and then copy this file in and try another non-indexed search to see if it improves the speed.
Okay, ran the same test on another computer and got the same results. When searching a music collection (my SteamLibrary) v22 finished in 2:00 while v23 finished in 5:40. Version 22 almost 3 times faster. On the same machined did search of video folder and v22 finished in 35 seconds, while v23 took almost 22 minutes.
Both searches had near the same number of matches, yet the video search took 37 times longer in version 23. The video library is flatter, but only has one file per folder. The mp3 library has a mix, but a lot of folders with many files.
I'm testing the 'dowshlp.exe' file now. Will post shortly.
Okay, these next tests are on my local SteamLibrary, which is not indexed.
(v23+ is v23 with dowshlp.exe file)
Searching for music (7567 files found): success
v22, 24 seconds
v23, 157 seconds
v23+ 24 seconds
Searching for DLL/BIN (13399 files found): success
v22, 36 seconds
v23, 537 seconds
v23+, 36 seconds
These next tests are on the same SteamLibrary, accessed via \uncpath from diff computer.
Searching for mp3 files (7567 files found): fail (split the diff)
v22, 120 sec
v23, 340 sec
v23+, 237 sec
I ran this last test three times. When replacing the 'dowshlp' file on v23, I get the same results as v22... except when I access a share. I was expecting 120 seconds, but took near twice that.
Thanks very much for that. Out of interest, would you be able to try this version as well?
dowshlp.zip (168.4 KB)
Alright! 
Most of the things I've tested with the new file, where real close to v12.22. Searching a network folder was the real surprise.
My video search over network drive went from: (non-indexed)
v23: estimate over 2 hours to finish .... (took 4 minutes to return 185 items)
v22: returned 6124 files in 119 seconds
v23+: returned 6124 items in 38 seconds (FileLocator did it in 33 seconds)
Searching local SteamLibrary for music was 24 seconds for 7567 files, same as v22
Searching local SteamLibrary for DLL/BIN was 34 seconds for 13399 files, v22 took 36 seconds
Searching local video folder took 5 seconds for 6124 files, same as v22
Looking much better.
Will this change persist in the next version update?
Yes this will be part of the next update. Thanks for your help in testing!
