If the frequency of my laptop's disk chirps are any indication, I'd say
hammie is about 3-5x faster than SpamAssassin.
Skip

I'm listed as a developer on SF and have the spambayes CVS module checked
out using my SF username, but I'm unable to write to the repository.  CVS
cvs [server aborted]: "add" requires write access to the repository

So then, Tim Peters <tim.one@comcast.net> is all like:
> I'm not sure what you're doing, but suspect you're storing individual
> WordInfo pickles.  If so, most of the administrative pickle bloat is
> due to that, and doesn't happen if you pickle an entire classifier
> instance directly.
Yeah, that's exactly what I was doing--I didn't realize I was incurring
administrative pickle bloat this way.  I'm specifically trying to make
things faster and smaller, so I'm storing individual WordInfo pickles
into an anydbm dict (keyed by token).  The result is that it's almost 50
times faster to score messages one per run our of procmail (.408s vs
18.851s).
However, it *does* say all over the place that the goal of this project
isn't to make the fastest or the smallest implementation, so I guess
I'll hold off doing any further performance tuning until the goal starts
to point more in that direction.  .4 seconds is probably fast enough for
people to use it in their procmailrc, which is what I was after.
> If you're desparate to save memory, write a subclass?
That's probably what I'll do if I get too antsy :)
Trying to think of ways to sneak "administrative pickle boat" into
casual conversation,
Neale

Your message of "Fri, 06 Sep 2002 22:17:28 PDT."
             <w53n0qubcpj.fsf@woozle.org>

> Yeah, that's exactly what I was doing--I didn't realize I was
> incurring administrative pickle bloat this way.  I'm specifically
> trying to make things faster and smaller, so I'm storing individual
> WordInfo pickles into an anydbm dict (keyed by token).  The result
> is that it's almost 50 times faster to score messages one per run
> our of procmail (.408s vs 18.851s).
This is very worthwhile.
> However, it *does* say all over the place that the goal of this
> project isn't to make the fastest or the smallest implementation, so
> I guess I'll hold off doing any further performance tuning until the
> goal starts to point more in that direction.  .4 seconds is probably
> fast enough for people to use it in their procmailrc, which is what
> I was after.
Maybe.  I batch messages using fetchmail (don't ask why), and adding
.4 seconds per message for a batch of 50 (not untypical) feels like a
real wait to me...
--Guido van Rossum (home page: http://www.python.org/~guido/)