#3730 Slower on-demand scan speed
Accepted, last edited by Jarvis last edited by Jarvis
Reproduction steps: Start a context-menu on-demand scan of my C drive using default settings.
Actual result: KES takes longer to scan the same files compared to KIS. Furthermore, skipping password protected files seems to take too long.
Expected Result: Same or even improved scan-performance. Fast skipping of password protected files.
In the following screenshots two consecutive context-menu on-demand scans were run.
KES scan-times with two additional copies of a few dozen password protected files:
Noteworthy: Kaspersky only makes use of about 4 cores/threads out of 24 logical cores of my CPU. As a result its bandwidth is much lower than what my CPU + M.2 SSD would be capable off. For comparison: the Windows' built-in AV solution takes less than 6 minutes to scan the same C drive and even seems to scan deeper into compressed archives (higher total number of files scanned).
Operating system: Win 10, x64
System: 5900X, MSI X570, 16 gb, M.2 SSD
Product Version: 188.8.131.524
Part of the problem might be that KES keeps writing a huge trace file of up to 5 gb (then starts a new file and goes on). At the same time Windows Recovery (System Volume Information) is growing in size, too, likely because the trace file resides in ProgramData and is thus copied by Windows.
I only just noticed that there is a dedicated "Performance" sub-forum. So despite this being about the on-demand scanner this report might better be moved there.
How do I disable the trace file creation for better performance comparisons? And with 5 gb trace files it's worth mentioning that even compressed to 7Z they are nearly 300 mb for uploads. ;)
So I managed to disable the Trace files, but Windows Restore still keeps writing to "System Volume Information" while a KES context-menu is running?!
Overall scanning performance still mostly seems to be bottlenecked by the small number of CPU threads being used by KES. This is especially true for compressed archive files which are only uncompressed and scanned by a single thread per file, even for very large files (like some jar libraries).
Can you please reproduce it on new 184.108.40.2068 build ?
we will need:
- product traces
, last edited by Timur Born last edited by Timur Born
I did more tests using the additional under-the-hood knowledge I attained. Disabling the trace file leads to KES "Full Scan" being nearly 10% faster (!) than KIS on both initial and consecutive scans (cache data being used). This is with iSwift/iChecker being enabled or disabled. So the initial slowdown I measured was due to KES enabling the trace file by default.
Furthermore due to the trace file not creating 5-10 gb of additional data per scan my Windows Restore (System Volume Information) folder grows far less.
When the trace is disabled then Kaspersky's ProgramData folder is up to double the size of Windows Defender's folder, but both are less than 1 gb in size. Once all AV caching data is created consecutive scans lead to less increase in the Restore folder, but Kaspersky seems to still cause slightly more writes there.
That being said I would still like for Kaspersky to (at least optionally) use more CPU threads for manual on-demand scans, because that seems to be the main bottleneck resulting in up to three (3) times slower on-demand scans compared to Windows Defender (or Bitdefender). While KES/KIS mostly only use 4 active threads the other two solutions use 24 threads. For comparison, Kaspersky peaks somewhere over 700 mb/s with averages well below 250 mb/s, WD peaks at over 2500 mb/s with averages considerably higher than KES/KIS.
Additionally KES/KIS sometimes seems to use a somewhat detrimental file access pattern. This results in my M2.SSD at some points measuring around 100% utilization while both SSD bandwidth and CPU load is low. This only happens seldom, though, so the CPU being not fully utilized remains as main bottleneck on my modern/fast system.
The original issue of KES scanning slower than KIS was solved by disabling the trace files. So there is nothing more to analyze or is there?
KES/KIS only using a limited number of CPU threads/cores seems to be a deliberate choice by your developers. You would have to ask your developers if this is by design or maybe a bug. Additional threads are used for real-time scans so overall KES is capable of using more, it just does not do so for on-demand scans.