http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5356
------- Additional Comments From [EMAIL PROTECTED] 2007-08-24 09:23 -------
I toyed a bit with this new feature, very nice, thanks!
(my last two checkins to trunk are some small streamlining there).
Now here is one (rather small) diff which may deserve attention of others.
It provides access to the timing report for a caller through a tag TIMING
through the usual $pms->get mechanism. I find it very convenient (amavisd),
not having to turn up SpamAssassin debugging just in order to get that report.
I'm checking it in to trunk, it is easy to take it out if it turns out
not to be desired:
svn -m 'Make a timing report accessible to a caller as a tag TIMING' ci
Sending lib/Mail/SpamAssassin/PerMsgStatus.pm
Sending lib/Mail/SpamAssassin.pm
Transmitting file data ..
Committed revision 569445.
One gocha is that timestamps need to be collected regardless
of would_log('timing'), so I'm commenting out jm's changes in #4.
>> What is the performance impact of adding all those calls?
> I've made it all conditional on would_log('timing') -- so now,
> lost in the noise, unless debug is active
A call to HiRes::time is very quick. There are some other simple
statements around, but it all looks very straightforward.
I'd say that taking out a call to would_log() already saves
a substantial proportion of the added overhead :)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
