Juhapekka Tolvanen wrote:
I don't see how just replacing the Bayesian part of SpamAssassin with something written in C is going to help. In fact, I'd be willing to bet that the overhead of starting up another program would consume more time than you'd gain from any efficiency increase. You'd have to rewrite the rule processing parts as well to get a real improvement. (If you want to try it, though, "Bogofilter" is a nice C-based Bayesian filter and quite simple to set up. I've used it for quite a while, but now I'm testing SpamAssassin as an added layer of protection.)On Wed, 22 Sep 2004, +22:45:09 EEST (UTC +0300), Dan Mahoney, System Admin <[EMAIL PROTECTED]> pressed some keys:
On Wed, 22 Sep 2004, Daniel Quinlan wrote:
Juhapekka Tolvanen <[EMAIL PROTECTED]> writes:
1) Switch off that Bayesian filter of SpamAssassin, because it is implemented in slow interpreted language called Perl.
2) Use DSPAM as Bayesian-like filter, because it is implemented in
lightning-fast compiled language called C.
Okay, and not to get off the topic on your opinion on perl versus c,
but the first thing perl does when it executes a script is compiles
it. This is why spamd is a decent solution despite being written in
perl, because it only starts up once.
I'm not saying that a constantly-running perl program is as fast as a
compiled C app all of the time, but if you're going to sit here and
suggest changes to the SpamAssassin development team without possibly
having evaluated 3.0.0-Release for 24 hours, you might want to drop
the condescending attitude, since I'm *sure* we all know what perl and
C are.
I really don't care about attitudes of author of DSPAM. I just want to
know, how much faster SpamAssassin will be, if its Bayesian engine is
replaced with something else, for example with DSPAM. It does not hurt,
if we try it out and see what happens. And it does not hurt, if people
have more alternatives.
Also, the question is "is SpamAssassin fast enough," not "could it be faster if it were rewritten in another language"? While the author of DSPAM is welcome to his opinion that running perl-based SpamAssassin on a production server is "a death wish," there are a lot of sites that *are* using it in production which seem to indicate the contrary. I think you'll find that people who write software are very partisan about their own work and aren't reliable sources for comparison with other packages.
Keep in mind, too, that unless you're so short on memory that your computer is constantly swapping, SpamAssassin generally spends most of its time waiting for responses from RBL network servers.
I expect it would be, with only 64 megabytes of RAM. I'd consider that inadequate for just about any purpose these days, especially with RAM so cheap.When I used SpamAssassin and its Bayesian filter in my home computer, it really was slow.
I reiterate: It does not hurt, if we try out and see what happens.Is that an offer to try it? There's nothing wrong with experimenting, but you shouldn't expect other people to spend time testing your ideas for you.
