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 2019/03/04 22:41:09 UTC
[Bug 7698] New: Prevent loading warnings.pm every eval statement
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
Bug ID: 7698
Summary: Prevent loading warnings.pm every eval statement
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: toddr@cpanel.net
Target Milestone: Undefined
Created attachment 5645
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5645&action=edit
Suggested fix.
Currently, lib/Mail/SpamAssassin/Plugin/Check.pm injects 'no warnings
q(uninitialized);' in every eval statement it compiles. This executes quite a
bit of code just to to set the COP hints at eval compile time. If we move the
no warnings statement just outside of the quoted eval call, then it will set
the hints on the COP that does the quoted eval call and it will be inherited.
This should help speed up the eval calls.
Proof of concept:
perl -w -E'use warnings; no warnings q(uninitialized); eval q{package bar; my
$foo; print $foo}'
Patch attached to ticket.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7698] Prevent loading warnings.pm every eval statement
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@apache.org
--- Comment #4 from Kevin A. McGrail <km...@apache.org> ---
Yeah, we are back on make test working on 3.4 and trunk and I'm trying to sneak
one more feature in to roll 3.4.3
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7698] Prevent loading warnings.pm every eval statement
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
Todd Rinaldo <to...@cpanel.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #5 from Todd Rinaldo <to...@cpanel.net> ---
Closing for now.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7698] Prevent loading warnings.pm every eval statement
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
Todd Rinaldo <to...@cpanel.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |toddr@cpanel.net
--- Comment #2 from Todd Rinaldo <to...@cpanel.net> ---
Those are fair points. I think the fix I probably want is to get rid of the
need for no warnings. Do you think that would be achievable?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7698] Prevent loading warnings.pm every eval statement
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
Henrik Krohns <he...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hege@hege.li
--- Comment #1 from Henrik Krohns <he...@hege.li> ---
Did you actually benchmark this? I can not see any difference over 1% margin of
error in debug timings with a massive ruleset.
Also the original "no warnings" only appear in do_head_tests, but your patch
affects _all_ calls of run_generic_tests. So it doesn't seem to make much sense
to commit at this time.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7698] Prevent loading warnings.pm every eval statement
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7698
--- Comment #3 from Henrik Krohns <he...@hege.li> ---
Future plan is to comb through all the eval stuff, perhaps get rid of it all.
There's already a big change coming though for security reasons very soon. I
know the code pretty well since I was forced to learn it for a month to get a
grasp for it, so I'd like to make it much more simple, but we'll see..
--
You are receiving this mail because:
You are the assignee for the bug.