Slow on-demand scan because of low core/thread usage

  • 14 September 2021
  • 7 replies

Userlevel 1



Is it intended that KIS only uses about 4 concurrent CPU cores/threads for on-demand scans (e.g. context-menu scan)? There are 12 physical / 24 logical cores on my CPU and KIS only uses a small part of that. As a consequence KIS is relatively slow for on-demand scans.


Here are some comparison numbers for my C drive (496298 files, including installers and archives):

xxxxxxxxxxxx : 4 min 16 sec, 1101467 files

xxxxxxxxxxxx : 5 min 4 sec, 1451487 files

xxxxxxxxxxxx (single thread!) :11 min 58 sec, 812339 files

Kaspersky: 12 min 47 sec,  938712 files


Thanks and regards.

7 replies

Userlevel 1

It’s also worth mentioning that KIS seems to use a file access pattern that slows down its own read performance on my M.2 SSD. As a consequence throughput is rather slow while the drive is reported as fully utilized. So a higher thread count might not even improve performance.

Userlevel 1


Userlevel 1

For comparison, this is what the fastest software is peaking at during a context-menu scan on my setup (12 core CPU + M.2 SSD):


Userlevel 7
Badge +8

In Kaspersky, the 1st scan will always take longer, but not the successive ones…


I never run Full Scans in my drives,  personally think it's a waste of time and resources, so I only run Quick Scans (adding some custom system folders, where malware usually attacks).


A small trick for Full Scan settings in Kaspersky:


Userlevel 1

I know about settings to only scan changed files and make use of Kaspersky’s own cache (which other solutions use, too). In fact KIS’ cache is aggressive enough to keep its state over computer restarts. (Is the timeout 8h?)


This is about performance of an original scan on modern hardware, not about how various programs try avoid repeated scans of “known” files (KIS does good there). The context-menu scan serves as a fair comparison basis.


And I did not even mention how all (!) antivirus solutions (including KIS) only use a single thread to uncompress and test archives.

Userlevel 7
Badge +8

Then only a KL dev can answer Your question :) You can also try to contact to KL support via My Kaspersky service...

Userlevel 1

It’s well possible that limiting the number of threads is intended by KIS, as kind of compromise between performance and load demands. Thus my original question about the “intention” of the current implementation.


I would argue that an on-demand scan should be more balanced towards scan performance, though.

And I also have to test how this affects real-time scans when many small files are accessed for the first time (and consequently checked for changes regularly).