Upgrade to clamav 0.90.2 makes scanning extremely slow

[Glenn Steen]

On 27/04/07, Richard Lynch <rich at mail.wvnet.edu> wrote:
> Out of curiosity I decided to do a little testing of the performance of
> the three ClamAV methods:  clamscan, clamdscan, and clamavmodule.  This
> is not meant to be a full blown scientific test, merely a quick "rough
> idea" measurement.
>
> I have a directory  with over 300 virus infected files in it.  Running
> the three methods shows...
>
>    clamscan:           11.68 seconds
>
>    clamdscan:           6.56 seconds
>
>    clamavmodule:    4.50 seconds
>
>
> Results for clamscan and clamdscan we obtained using the "time"
> command.  Results for clamavmodule were obtained using the perl
> Time::HiRes module.  I had to use that to avoid adding in the time for
> the initial database load.
>
>
> This is pretty much what I expected.  Clamavmodle is the quickest since
> it doesn't have to load the database on every scan and it calls the
> ClamAV libraries directly.   Clamdscan is next since it doesn't have to
> load the DB every time but it does have the overhead of the
> communications with the clamd process.  And clamscan is slowest (by a

Don't forget the additional fork/exec bit either... Every cycle counts:-).

> significant margin) since it has to load the database on every batch.
>
> So, performance wise, clamavmodule is the best.  However, it does have
> the problem with being kept up to date with ClamAV changes.  Clamdscan
> is a little slower but avoids the problem with development changes in
> ClamAV.
>
Yes, byt basically you are showing that Jules is right that there is
no real big performance reason to implement clamdscan in MS... Then
again, if enough people want it, he'll likely add it just to keep 'em
quiet:-):-). ... Once he's well enough, of course.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se