Robert Rohde wrote:
On Wed, Mar 18, 2009 at 8:00 PM, Andrew Garrett
<andrew(a)epstone.net> wrote:
<snip>
To help a bit more with performance, I've
also added a profiler within
the interface itself. Hopefully this will encourage self-policing with
regard to filter performance.
Based on personal observations, the self-profiling is quite noisy.
Sometimes a filter will report one value (say 5 ms) only to come back
5 minutes later and see the same filter report a value 20 times
larger, and a few minutes after that it jumps back down.
Assuming that this behavior is a result of variations in the filter
workload (and not some sort of profiling bug), it would be useful if
you could increase the profiling window to better average over those
fluctuations. Right now it is hard to tell which rules are slow or
not because the numbers aren't very stable.
Yes, in one filter (filter 32) I've been watching, it was taking
90-120ms for what seemed like simple checks (action, editcount,
difference in bytes), so I moved the editcount check last, in case it
had to pull that from the DB. The time dropped to ~3ms, but a couple
hours later with no changes to the order and its up to 20ms.
Related to this: It would be nice if there was a chart or something
comparing how expensive certain variables and functions are.
--
Alex (wikipedia:en:User:Mr.Z-man)