First, let me outline a typical use case: a user opens a file in a foreground application. Avast will intercept calls to open a file regardless of its priority (or should, if it's configured the hooks properly). If a user opens a file, the program (or thread) will block until the scan is complete and the file open call returns, and as such will not be consuming any CPU. Therefore, the foreground user program opening the file is not competing for CPU with Avast and there is no need to raise Avast's priority to insure that the scan occurs. The user will wait the same amount of time if she opens a file with an application in either case, regardless of Avast's priority.
However, if there are many programs running on your computer (as there are mine,) then there are often
background tasks opening files and doing other things that Avast intercepts and scans. In this case, the user is
not the one opening the file, and is involved in doing something else in the foreground with a normal priority user application. When the background task opens a file, Avast's high priority preempts the user's normal priority program, and her computing experience is interrupted.
This happens to me a lot, and it bugs me. A lot.
So, your assertion that the scan should happen quickly depends, in reality, on why the scan is occuring. IMHO, it's absurd to interrupt the user because a background task requested a file open, or because Avast decided to check for a database update, or any one of the other background types of things it does. I also notice little freezes and interruptions just before Avast pops up its little "a virus database update is available!" messages. Grrr. (As an aside, it bugs me that I can't make those go away without clicking on them, and they hide other things I have stashed in that corner. Grr.)
As I've tried to explain above, if the user is the one opening the file, odds are that there is no competition for CPU anyway. It's possible that there may be background tasks consuming a lot of CPU. If this is a concern to the developers, they can check to see if the CPU is > N% busy with normal priority work and if the file open is being called by a foreground application If so, they can change the scan thread priority temporarily at that time. My bet is that will hardly ever happen. Well-behaved background processes should set their process priorities below normal.
I find a lot of anti-virus software writers set their process priorities to high because they fail to think through this sort of use case/scenario and mistakenly assume that if they don't set their process priority to high, their work will not finish as quickly. If there is no CPU competition, process priority is irrelevant. McAffee bugs the crap out of me at work for the same reason. If your mouse drifts across a large zipfile, or god forbid, a 7-zip or bzip2 file that isn't recognized, explorer accesses the file to show you the popup info tooltip and your machine is useless until the on-access scan times out (45 seconds in my environment, and no, users can't change the time or the behavior.)
I can change the process priority manually with ProcessExplorer (not Task Manager, which is crippled in this respect), but I shouldn't have to. Further, during startup when Windows is thrashing the disk launching services and Avast is blocking the user from doing anything as a result, you can't launch ProcessExplorer (or anything else, really) until it all settles down. I even have some hope that reducing the process priority will allow me to start using the machine (launching apps, etc.) faster than things currently operate during startup.
Hope that clarifies things!
Best,
tribble
