You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2022/03/06 14:11:27 UTC
[Bug 7962] New: [review] Deprecate sa-compile in 4.0.0
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
Bug ID: 7962
Summary: [review] Deprecate sa-compile in 4.0.0
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: sa-compile
Assignee: dev@spamassassin.apache.org
Reporter: apache@hege.li
Target Milestone: Undefined
I'm calling vote for officially deprecating sa-compile in 4.0.0.
While it might have been a novel concept over decade ago, time has passed it
and any "savings" it might give. We have no manpower to support all the complex
inner workings of BodyRuleBaseExtractor/re2c/etc.
We can keep the code in trunk for now, but should clearly mark everything as
deprecated without further support. Tempted to remove anything related to it in
4.0 svn branch (if we create one).
+1
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] [review] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
--- Comment #3 from Henrik Krohns <ap...@hege.li> ---
Some quick benchmarks with 100 emails
sa-compile stock
18.47user 0.15system 0:18.62elapsed 99%CPU (0avgtext+0avgdata
129804maxresident)k
18.49user 0.11system 0:18.61elapsed 99%CPU (0avgtext+0avgdata
128388maxresident)k
stock
20.95user 0.08system 0:21.04elapsed 99%CPU (0avgtext+0avgdata
126452maxresident)k
20.75user 0.21system 0:20.97elapsed 99%CPU (0avgtext+0avgdata
124616maxresident)k
sa-compile massive rules
37.11user 0.32system 0:37.91elapsed 98%CPU (0avgtext+0avgdata
231652maxresident)k
37.48user 0.23system 0:37.82elapsed 99%CPU (0avgtext+0avgdata
232732maxresident)k
massive rules
54.89user 0.18system 0:55.19elapsed 99%CPU (0avgtext+0avgdata
211108maxresident)k
53.17user 0.28system 0:53.57elapsed 99%CPU (0avgtext+0avgdata
210512maxresident)k
Maybe 10% speedup with completely stock trunk (<400 body rules). 30% when there
are heaps of extra rules (heinlein, KAM etc, 3000+ body rules).
I guess I'll spend a little more of my holiday verifying that mass-check
results are identical with and without sa-compile, with regards to all the
UTF-8 stuff etc..
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #4 from Henrik Krohns <ap...@hege.li> ---
Forget about it, I guess most issues are now fixed.
Sending
spamassassin-3.4/lib/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm
Sending spamassassin-3.4/sa-compile.raw
Sending trunk/sa-compile.raw
Sending trunk/t/sa_compile.t
Transmitting file data ....done
Committing transaction...
Committed revision 1898791.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] [review] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billcole@apache.org
--- Comment #1 from Bill Cole <bi...@apache.org> ---
(In reply to Henrik Krohns from comment #0)
> I'm calling vote for officially deprecating sa-compile in 4.0.0.
>
> While it might have been a novel concept over decade ago, time has passed it
> and any "savings" it might give.
I don't doubt this, but I expect we might get some resistance from people who
have used it as part of their routine workflow for so long, based on that
obsolete premise. Do you know of any specific test which will confirm that it
is no longer worthwhile?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] [review] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
--- Comment #2 from Henrik Krohns <ap...@hege.li> ---
(In reply to Bill Cole from comment #1)
> I don't doubt this, but I expect we might get some resistance from people
> who have used it as part of their routine workflow for so long, based on
> that obsolete premise. Do you know of any specific test which will confirm
> that it is no longer worthwhile?
It can provide marginal speed and memory savings, at the cost of lots of
complex codebase and tools that can break. Makes no difference to me if someone
would resist or not, it's up to the project to decide what it can and wants to
support. A bit of the same case as TxRep, a thing just barely works.. and as
such I would maybe keep it distributed, but with a "use at your own risk"
clause.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[review] Deprecate |Deprecate sa-compile in
|sa-compile in 4.0.0 |4.0.0
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7962] [review] Deprecate sa-compile in 4.0.0
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7962
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |4.0.0
CC| |apache@hege.li
--
You are receiving this mail because:
You are the assignee for the bug.