https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5590
--- Comment #23 from Justin Mason <j...@jmason.org> 2010-01-17 16:24:37 UTC ---
(In reply to comment #22)
> (In reply to comment #21)
> > btw, I think this significant slowdown in 3.3.0 may be as a result of
> > increased use of replace_rules rules, compared to when bug 4596 happened.
>
> Are you suggesting replace_rules itself has an impact on the performance? I
> doubt that, as replace_rules only comes into play at compile time.
>
> I will, however, grant that replace_rules makes it easier to write very
> complex
> (and thus slow) rules...
the latter -- I think some aspect of those complexities is performing very
badly without "use bytes", compared to with.
fwiw, I did a mass-check with and without "use bytes" in Message.pm, using perl
5.8.8, against 5000 ham and 5000 spam:
: 36...; wc -l log.trunk/*.log
5002 log.trunk/ham.log
5003 log.trunk/spam.log
10005 total
: 37...; wc -l log.bytes/*.log
5002 log.bytes/ham.log
5003 log.bytes/spam.log
10005 total
: 31...; ./freqdiff -c log.trunk/ham.log log.bytes/ham.log
4 __HIGHBITS
: 32...; ./freqdiff -c log.trunk/spam.log log.bytes/spam.log
-2 __TVD_SPACE_RATIO
so that's a barely-noticeable difference of 4 mails (out of 5000 hams) more
__HIGHBITS hits, and 2 less __TVD_SPACE_RATIO hits in spam. no scoring rules
were affected.
speed was not noticeably affected, either; ~50 mins with trunk, 48 with "use
bytes".
locale was set to LANG=C.
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
