From: Nix [mailto:[EMAIL PROTECTED]
>
> On 26 Nov 2006, [EMAIL PROTECTED] told this:
> > From: "Nix" <[EMAIL PROTECTED]>
> >
> >> On 20 Nov 2006, Giampaolo Tomassoni spake thusly:
> >>
> That's not even mentioning the metaprogramming and higher-order
> programming techniques that we use
On 26 Nov 2006, Tom Allison uttered the following:
> I could see doing something in C/C++ but definitely not Java...
> Similary, for performance reasons I would stay away from Ruby.
The performance that matters for SA is the performance of the regular
expression matcher. That's the only part that
On 26 Nov 2006, [EMAIL PROTECTED] told this:
> From: "Nix" <[EMAIL PROTECTED]>
>
>> On 20 Nov 2006, Giampaolo Tomassoni spake thusly:
>>
That's not even mentioning the metaprogramming and higher-order
programming techniques that we use extensively in SpamAssassin -- those
are basical
Nix wrote:
On 20 Nov 2006, Giampaolo Tomassoni spake thusly:
That's not even mentioning the metaprogramming and higher-order
programming techniques that we use extensively in SpamAssassin -- those
are basically *just not possible* in C/C++. ;)
Ops. What's this stuff? Let me know.
eval and al
From: "Nix" <[EMAIL PROTECTED]>
On 20 Nov 2006, Giampaolo Tomassoni spake thusly:
That's not even mentioning the metaprogramming and higher-order
programming techniques that we use extensively in SpamAssassin -- those
are basically *just not possible* in C/C++. ;)
Ops. What's this stuff? Let
On 20 Nov 2006, Giampaolo Tomassoni spake thusly:
>> That's not even mentioning the metaprogramming and higher-order
>> programming techniques that we use extensively in SpamAssassin -- those
>> are basically *just not possible* in C/C++. ;)
>
> Ops. What's this stuff? Let me know.
eval and all t
That's not even mentioning the metaprogramming and higher-order
programming techniques that we use extensively in SpamAssassin -- those
are basically *just not possible* in C/C++. ;)
--j.
Matt Kettler writes:
> Giampaolo Tomassoni wrote:
> > From: Matt Kettler [mailto:[EMAIL PROTECTED]
> >
>
From: Matt Kettler [mailto:[EMAIL PROTECTED]
> Giampaolo Tomassoni wrote:
> >
> > ...omissis
> >
> > But if we are speaking of a /10 mem*cpu factor, well, it could
> > easily be interesting, isn't it?
>
> No. I think it would be patently stupid because of the massive effort
> involved and loss o
Giampaolo Tomassoni writes:
> > > > Recently in the perl "blead" code, one of the perl hackers has
> > > > added a trie-based regexp matcher (with Aho-Corasick
> > > > optimisations) to efficiently match multiple regular expressions
> > > > in parallel, to the perl core regexp matching code. That
Am 17.11.2006 um 20:36 schrieb Eric A. Hall:
Thinking about the GPL Java announcement some, and trying to
imagine the
kinds of opportunities this allows for, it occurs to me that
SpamAssassin
might be a natural fit for Java.
Why on earth do you come to that conclusion and what does Java
Mark Martinec wrote:
> On Friday November 17 2006 21:24, Giampaolo Tomassoni wrote:
>
>> Besides, if there wasn't SA pluging, I would prefer a C/C++ version of SA.
>> Wouldn't it run better? Wouldn't it be faster, wouldn't have a smaller
>> memory footprint, better reclamation, better hooks for
Mark Martinec writes:
> On Friday November 17 2006 21:24, Giampaolo Tomassoni wrote:
> > Besides, if there wasn't SA pluging, I would prefer a C/C++ version of SA.
> > Wouldn't it run better? Wouldn't it be faster, wouldn't have a smaller
> > memory footprint, better reclamation, better hooks for
On Friday November 17 2006 21:24, Giampaolo Tomassoni wrote:
> Besides, if there wasn't SA pluging, I would prefer a C/C++ version of SA.
> Wouldn't it run better? Wouldn't it be faster, wouldn't have a smaller
> memory footprint, better reclamation, better hooks for plugins etc? :)
...and buffer
Giampaolo Tomassoni writes:
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >
> > ...omissis
> >
> > Recently in the perl "blead" code, one of the perl hackers has added a
> > trie-based regexp matcher (with Aho-Corasick optimisations) to efficiently
> > match multiple regular expressions in
well...
I spent several years writing Java in the '90s, and am quite certain that
SpamAssassin would perform a *lot* worse if written in Java.
SpamAssassin is heavy on regular expressions, and *very* optimised for
Perl's VM.
On top of that, I'm pretty sure it would be quite hard to get fast
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> ...omissis
>
> Recently in the perl "blead" code, one of the perl hackers has added a
> trie-based regexp matcher (with Aho-Corasick optimisations) to efficiently
> match multiple regular expressions in parallel, to the perl core regexp
> matchi
Giampaolo Tomassoni writes:
> From: Matt Kettler [mailto:[EMAIL PROTECTED]
> > 1) perl has a substantial base of text parsing and utility libraries
> > that no other language can match.. Java does have native regex
> > support, so it has a leg up over the others,
>
> Right, but both langs are not
Giampaolo Tomassoni wrote:
> From: Matt Kettler [mailto:[EMAIL PROTECTED]
>
>> 1) perl has a substantial base of text parsing and utility libraries
>> that no other language can match.. Java does have native regex support,
>> so it has a leg up over the others,
>>
>
> Right, but both langs
From: Matt Kettler [mailto:[EMAIL PROTECTED]
> 1) perl has a substantial base of text parsing and utility libraries
> that no other language can match.. Java does have native regex support,
> so it has a leg up over the others,
Right, but both langs are not that much suited for scoring a message:
> This was with amavisd-new, but should not be much different than
> spamd, except for somewhat smaller daemon main program in clamd.
s/clamd/spamd/
On Saturday November 18 2006 02:05, Matt Kettler wrote:
> I also expect a lot of the memory usage is the annotation tables and
> such for regexes. It would be interesting to compare the size of spamd
> without any rules loaded against one with a stock ruleset. The
> difference between the two can't
Eric A. Hall wrote:
> Thinking about the GPL Java announcement some, and trying to imagine the
> kinds of opportunities this allows for, it occurs to me that SpamAssassin
> might be a natural fit for Java.
>
> I'm just thinking out loud here, not advocating anything...
>
> Would it run better? Woul
Giampaolo Tomassoni wrote:
Thinking about the GPL Java announcement some, and trying to imagine the
kinds of opportunities this allows for, it occurs to me that SpamAssassin
might be a natural fit for Java.
I'm just thinking out loud here, not advocating anything...
Would it run better?
What
> Thinking about the GPL Java announcement some, and trying to imagine the
> kinds of opportunities this allows for, it occurs to me that SpamAssassin
> might be a natural fit for Java.
>
> I'm just thinking out loud here, not advocating anything...
>
> Would it run better? Would it be faster, ha
24 matches
Mail list logo
