I'd expect it to depend on the same processes as Explorer, but don't know the implementation details of it. (I am not sure if they are published anywhere. Windows Search is like a black box to us. We call the OS API with parameters and get back the results it gives us, but the steps in between are unknown.)
If Explorer's search is using the index then the dependencies are probably running (although the shell is known to take shortcuts sometimes, with 3rd party software using the published APIs going a slightly different route at times, which could be the difference).
One thing to check is to make sure dopus.exe is not running elevated as that could cause problems for parts of the search API to communicate across processes. Using UAC within Opus, and Opus's Admin Mode, are both OK, but you don't want to run the whole process elevated (see here for more detail).
It could also be something like antivirus slowing things down, treating Opus differently to Explorer.
Or it could be that the search itself is running at the same speed but something on the Opus side is bottlenecking the feed of results. (If so, it may or may not be part of Opus itself, but would be something inside the Opus process.) If the bottleneck is happening, I'd expect similar slowness if you did a Find (not search), restarted Opus, and then went back to the Find Results collection to display it again (without re-running the Find). If re-displaying the results is slow then let us know here and we can go into diagnosing a possible cause.