Could malwarebytes be coded to enable "multiqueue" support for ssd's?

[Duckers]

I saw that malwarebytes read the files pretty slow even on a 970 evo because it only used it as one request at a time. But what if you enable or write an algorithm in malwarebytes to have up to 32 requests at a time? Say queue 32 files to scan each time. That way you can utilize the 4k Q32 depth and get to use the full 290.000 iops all at once to scan with instead of Q1 which only is 15.000 iops for one file at a time. Much shorter scan time.

[exile360]

Greetings,

I'm not certain how they've implemented the scan engine, but I do know that as it is, at least by default it does pretty much max out resource usage.  The engine is multi-threaded and utilizes RAM generously to load the full database into memory and maximize scan speed.  I also know that it heavily relies on caching so that subsequent scans during the same Windows session are massively accelerated with much less disk access required (I've observed this first-hand based on the total lack of activity from my system's disk activity indicator LED following the first completed scan).  I have a 1TB Samsung 960 PRO and an i7 7700K overclocked to 4.6GHz on all cores, and with rootkit scanning enabled, my scan times are around 40~50 seconds for a Threat scan (the default scan type) and I just ran a scan to test and it only took a total of 43 seconds.

I will submit a request for this enhancement, however I do know that they have already massively improved scan performance in the engine over the past few years as it has been a key area of focus and I actually worked directly with the lead engine developer for a long time on scan engine optimization back when I was QA for Malwarebytes and we tested a large array of builds with different enhancements, tweaks and alternative scan engine implementations to find the combination with the best performance.

If you have any further feedback or feature requests please don't hesitate to let us know.

Thanks

[Duckers]

22 hours ago, exile360 said:

Yeah, i know they have made amazing progress. It is optimized cpu and ram wise, but i feel like it could use a "ssd optimization" as well to use as much as it can from this !queue depth ssd's has over hdd's. So say for us who has a beefy cpu to have the free performance to scan much faster, it would benefit us greatly to be able to scan big ssd's much faster by utilizing multi QD engine to adaptibly select say a select amount of clusters to each QD "thread" to make the most out of ssd's. 

Cause quick scans are fast. But if say we want to do one throughout scan of the whole ssd for instance. Hdd's will be slow by default because of the mech arm.

And thanks for forwarding this to the developers  I won't expect them to make it a reality within the next few months as that sort of "algorhithm" can take a good amount of months to figure out as i don't know if there's any other normal end user programs that can utilize the QD unless it's servers or VM's that the ssd itse'f or the ssd driver "queue's" 

So the malwarebytes scan engine could be programmed to act as several instances requesting one file after the other simultaneously. That way the scan can be possibly near 20fold faster.

 

[exile360]

The only reservation I have is that I watch CPU activity closely during scans and generally speaking it pretty much maxes out every thread, at least on my 7700K (4 cores, 8 threads) throughout most of the scan process.  This makes me think that it likely is using each available CPU thread to analyze at least one file, or to perform an individual analysis of various aspects of a file (since there are multiple criteria in the database for determining whether an object is malicious or not; it isn't just a raw hash check of the files on disk as it must look at everything from filename, path, internal file structure, file type analysis, metadata and other types and levels of file structural and behavioral analysis), but looking at the speed of my scans I hypothesize that they likely are analyzing at least one file per thread at a time throughout the scan process.  If the number of available threads for a given system is the bottleneck then increasing the volume of files on disk that can be queued up or analyzed at one time might not provide any performance benefits, however I'd have to leave that to the Developers to determine obviously.  I'm just speaking from my own perceptions based on my own observations and experiences with the software on my own systems.