It might be relevant to this discussion that we've developed a drop-in wrapper
acceleration application that uses our specialized hardware to get between 8 and 570
(depending on rules used) times the performance of SpamAssassin on its own.
We tried libpcre for comparison and as people here speculated, we found that it is only
marginally faster than Perl. Multi-pattern algorithms tend to use up an unreasonable
amount of RAM with SA signatures.
Guy
mouss wrote:
Justin Mason a écrit :
There was an attempt several years back, by one of the MPlayer guys iirc.
It might be worth searching archives for that if you're still interested.
For what it's worth, I can tell you with almost 100% certainty that it's
pointless. It may reduce memory usage, but will have minimal effect on
runtime; as John says, perl's regex engine is written in C too, so there
won't be any speedup in that code at all, and that's the main bottleneck
by far. The only way to speed that up is to rethink the regex engine
itself.
I think a multi-pattern algorithm would speed up matching. (of course,
this doesn't mean rewriting SA in C. it suffices to have a perl interface).
SpamAssassin is pretty well designed, speed-wise; the bottlenecks are
mostly outside of the interpreted language parts. Perl is quite good
about allowing you to get C speed for your hot-spot code, if you know
how.
I guess the problem isn't perl by itself, but the quality of the modules
you use. after all, the machine doesn't speak C or perl.
--
Guy Tsafnat
Anti-Spam Team Lead
Sensory Networks Pty. Ltd.
Level 6, 140 William St.
East Sydney NSW 2011
AUSTRALIA
Direct +61 2 8302 2740
Phone +61 2 8302 2700
Fax +61 2 9475 0316
Mobile +61 415 481 043
The information transmitted is intended only for the person to whom
it is addressed and may contain confidential material. Review or
other use of this information by persons other than the intended
recipient is prohibited. If you've received this in error, please
contact the sender and delete from any computer.
