Is SpyBot scanning multithreaded ?

[CarefreeComputers]

Hello all
Firstly I'd like to say that Spybot is by far and away my favourite anti-spyware product, bar none!

Its consistently kept me and my clients safe from threats for the last few years. Bravo everyone involved.

That said I have one query regarding the way SpyBot performs its scan.

What I want to know is, is SpyBot a multithreaded application?

For most people this wont be much of an issue as its sounds a bit technical, which it is. Basically a multithreaded application takes advantage of there being more than one processor in the system its running on.

A few years ago a multi-processor system would have been fairly unusual outside of a server setting but as more and more peoples home computers have a dual-core (or more) processor this starts to become an issue.

I suspect that SpyBot is NOT a multi-threaded application as I've just run it for the first time on my brand new Dual CPU - Dual Core system and it took roughly 10 minutes!

(Also I reran the scan and checked it out in Process explorer and there was just one thread taking resources).

IMMO running the various scans types SpyBot performs concurrently (at the same time) would reduce the scan time dramatically!!

I'd this something the SpyBot team are considering implementing?

(BTW as a developer myself I'm quite aware how simple my request sounds and how horrendously complicated concurrent programming is in real life :devilpoin:)

[PepiMK]

You're indeed right, Spybot-S&D currently use more or less single-threaded; of course, the "worker" thread is separated from the GUI, and some very minor tasks are threaded, but the bunch of work is done by one thread.

And of course you're right about the "horrendously complicated" thing ;)
The first issue is concurrent file access might not always speed things up; just test copying two larger files from the same partition at the same time, and with copy tools showing throughput, you might notice that it would be faster to queue them. But of course the filesystem is not the only thing scanned; s, a few years ago we had a bi-threaded new engine ready, with one thread working the filesystem, and one the registry (actually, a third one for a lot of special stuff, but that doesn't count in terms of overall time).
That engine never made it to the public for one reason: the complexity of malware evolved. With regular anti-virus applications, you usually scan one file at a time, by itself. Spybot-S&D got more complex than that - with some malware using random names, detection "rules" are sometimes interlinked, e.g. using a filename of an identified file for a later registry check.
Plugins are another issue, since they add functionality that the main engine didn't know at compile time, thus creating problems in interpreting dependencies (for unknown database "commands", the engine wouldn't know in which data field to look for the dependency information... but this can be overcome as well of course by separating that kind of information into another, small file that could be updated easilier).
I guess all that would be easier to understand if we would finally upload an updated sbi file format documentation ;)

With so many rants on complexity, I'm not trying to say it is impossible, nor that it won't be done though. In fact, all newly written code has key aspects on a type of code reorganization that combines flexibility and improved quality assurance possibilities, which will make future multithreading easier. We haven't decided on the exact splitting point though - that would either be files vs. registry again with quite a bit off logic to avoid deadlocks and long waits required, or on a database file level, where the challenge would be for example shared vs. separate caches.

Oh, one further issue is there of course: Spybot is consuming a lot of processing power, and taking both cores in a dualcore machine would mean putting Spybot to the background still doesn't leave a lot of power to the front apps. Anyway, since multithreading would be an option, that wouldn't be an excuse ;)

[CarefreeComputers]

wow my goodness thats some reply!
Look likes the issues involved have been thought over long and hard.

I had no idea that the scanning was combinational which must make the code much more complicated.

Having studied parallel processing at university I know 1st hand how easy it it do end up with a result that produces a performance difference of only a few percent while investing lots of time.

Many thanks for the detailed reply.