Scaner (and probably rest of app) is single-threaded

Attention: Eset apps are single-threaded

Greetings,

NOD32 is one of the fastest av's on the market. In order to maintain this position I suggest making Eset apps v3 multi-threaded, so all CPUs/Cores could be used for computations.

Peter

 

Have you considered that each thread would be scanning different files at different places on the disk at a time and thus slowing down disk access for other applications?

 

Perhaps have an option to switch between single/multi-threaded scans? If you arent doing anything else on your machine during the scan, multi-threaded would be a good idea. I find that a lot of programs (in my experience anyway) dont really take full advantage of Core2's or quads.

 

I mean only computation threads, not I/O ones. For example, single thread loads 40mb exe file to memory and N threads analyze this exe. N = No of CPUs/Cores.

 

I guess that making Advanced Heuristics multithreaded could help a lot with the occasional freezes when processing SFX/UPX files.
I think that a optimized scanning engine could process files at the maximum speed allowed by the HDD.

 

Currently the scan is run in one thread so that the other core can fully serve for the system and other applications. Or if you wish you can run another scan simultaneously and the OS will automatically use the other core for that scan.

 

I need some help here, maybe I am wrong.
1. On-demand: I want to scan a file, folder, disk, system, and I want it now. Well, I think I want it to be done as fast as possible, I don't really care about the other applications running at that time.
2. Shield: from what I know, the shield is always scanning a file and after that allows access to it, or execution. Then the same ideea applies here also: faster/better. Example: Office or IE. When running any application, is not just the main exe file that is loaded (scan), there are also some dll's loaded (scan). I don't know if Word can be started just with the exe, with the dll's still beeing scanned (no access to them). Or am I wrong? How much CPU can this take? Will the scanner use 100% of a multi-core (2-4 now, maybe more next year) for <10 MB files and for how long?
3. Planned: well, here I don't want the scanner to use 100% of the multi-core. But from what I know the programmer can set a priority for the thread so that the OS can know how much of the CPU power (idle %) to assign to each application.

So the answer is YES, please support multi-core.

 

PMI is right. Starting second instance to do another job is out of consideration. Just use all cores and add ability to set priority of scan (idle, below normal, normal, above normal, high; realtime not recommended even as option).

BTW. Office has plenty of dlls and exes which have >10mb size. Also scanning archives and email databases is cpu intensive.

PS. I don't know which compiler ESET use, but I heard that ICC is the fastest one.

 

I asked about the 10MB files just to have a scale of how fast the scanner could be in multi-core. And Winword in Office 2003 has 8.4 MB, so files under 10MB could include more then 90% of the files one can have on a disk. (I don't have exact statistics)

 

Forget big exe files. Multicore support is especially needed for scanning archives and mail bases. Also advanced heuristcs is CPU intensive. Archives, e.g. 2gb size need to be unpacked before scanning. Unpacking of such big archive takes MUCH CPU power ! This is the reason why I never scan (or scan once) archives...

About numer of CPU cores. Two cores are now a standard for new computers. In 2008 4 cores will be standard, In 2009-2010 8 cores...

BTW. It looks like, that 8-core CPU is capable of realtime raytracing. Games support for this technology will boost multicore market.
Link: http://www.pcper.com/article.php?aid=455

Anyway, keep in mind: MULTIPLE CORES HAVE FUTURE, surely. This is direction, where cpu companies are heading.