I have a problem with Dopus search today. When I enter a search term into the search box Dopus take a long time to find all files containing that term, and sometimes becomes unresponsive.
I think I caused this problem yesterday by overzealously using Autoruns to disable what I thought were obsolete start-up items across my whole windows 7 installation. Prior to today Dopus searches were very fast so this is a new problem and probably not a defect in Dopus or its upgrade.
Dopus seems to be the only program affected; searches in Windows Search (native) are fine, as are searches within Outlook. Windows Search is running and is indexing new items.
I suspect that Dopus is not querying the Windows Search database and is instead searching the slow way - as it does with "Find". Is this plausible? If so which Win 7 startup items might I have inadvertently disabled which might be preventing Dopus accessing the Windows Search database?
This problem manifested today in Dopus 11.something. Upgrading to Dopus 12 hasn't resolved it.
I may have the wrong idea about the Windows Search database so any ideas/suggestions also gratefully received!
Prefixing with "filename:" is also very slow, although it does return correct results after some time. So it's slow searching both for filenames, and for text within files.
Is it similarly slow to use the Find panel, or is only the Windows Search field slow for you?
Can you see or remember what you disabled with Autoruns and re-enable it (and reboot) to see if it was what made the difference? I think Autoruns will show the disabled items, if I remember correctly.
The "Find" panel is about the same speed as using "Search" now. Previously, "Search" was much faster (as it uses the Windows Search database whereas my understanding is that "Find" does not).
In Autoruns I have re-enabled everything I remember changing.
Are there any processes upon which Dopus depends to access the Windows Search database? if so I'd like to check that is running.
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.
Having done some more work on this I can't see how my changes to start-up items could have caused this problem. It may be, as you suggest Leo, a virus scanning problem caused by a recent Windows update or a change to MSE virus definitions.
My virus scanner is Microsoft Security Essentials. If I add dopus.exe as an "excluded process" then Dopus searches are very much faster; back to normal. However, MSE warns that "When you add a process..." [to be excluded] "...any file that the process reads from or writes to will be excluded from a scan.". This is obviously a concern.
AV scans memory and system file operations. I don't think that any virus will use Opus internal commands to infect your computer so even if you copy infected file, nothing happens - virus, like any other program, must be activated before will be dangerous. Until then it's just a file, like all others. And even exe file with virus, if accidentally started, have separate process that is not excluded from scan and your AV will block that process.
Anyway - viruses are dangerous and can slow down your computer only when they're active, antivirus slow down your computer all the time and his behaviour is not that different that virus (prevents files from start sometimes, slowing down your access to files, increasing system boot time and even can delete some files if you get false positive alert - looks like description of very aggressive virus to me, isn't? ;).
MSE warning are not "obviosuly a concert". Microsoft warns you all the time about potential security risks every time you want to make your life a little easier.
Microsoft's antivirus scanner can cause some major slowdowns, we have found. (Not just us, there are lots of threads about it on the web, but it definitely affects Opus as well.) It seems to re-scan files even when they have not changed, and even when they are opened as data (not executable) it can make the file open take several seconds per file, when it normally takes a tiny fraction of a second per file. (And that is before any data has been read from the file, so just reading one byte can take several seconds.)
All antivirus imposes some speed penalty of course (nothing is free) but MSE seems particularly bad, at least in certain situations. Good scanners will avoid re-scanning a file they've already scanned recently, which helps a lot as you only get the delay once for each file.
Agreed that AV can in general cause headaches. However, this is new behaviour. Although I haven't changed my Microsoft Security Essentials settings at all MSE has in a few days gone from playing entirely nicely with Dopus to causing a problem.
