Robert Rohde wrote:
On Wed, Mar 18, 2009 at 8:00 PM, Andrew Garrett andrew@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.