[Zope-dev] Call Profiler

[Richard Jones]

On Fri, 1 Feb 2002 21:53, seb bacon wrote:
> I wrote:
> > I've just announced our Call Profiler product on zope.org and the zope
> > announce list (waiting for people in different timezones to authorise
> > them :) ( http://www.zope.org/Members/richard/CallProfiler/  for the
> > impatient)
>
> This is absolutely excellent, well done and thanks :)  I added various
> FSObjects to the profiled modules list and have been looking at my CMF
> systems - it's really instructive.

Please send me the config entries for them. Also, if anyone has used ZPT with 
it, let me know if my guess of the config for them is correct :)


> > On one hand, the performance hit when dynamically patching the methods is
> > zero when the product is not "active", but it does mean diddling with
> > methods that really probably should be left alone. On the other hand,
> > having changes to the core code to test for profiling being enabled
> > introduces a small performance hit even when profiling is not activated.
>
> You could do this check only if zope is being run in debug mode; then
> there would be zero perormance hit in production sites.

No, there's still the performance check for "am I in debug mode?" which is 
equivalent to "am I in profiling mode?". Sure, it's small, but it's there.


> > Any comments?
>
> I think the reporting could do with some usability improvements.  It's
> good now, but takes a while to navigate round.

Yep, I know :)


> - All the reports could benefit from being sortable by column.

In the works already :)


> - the trace for a complete template could be slightly clearer.  The
> colour coding for the start and end of a module could have a clear
> legend, for example.

I'll put a legend in. Is the colour coding what you meant by "clearer" or is 
there something else? 


> - there needs to be some solution for really long URLs, which require
> lots of horizontal scrolling - just displaying the final parts of the
> path, with the rest of the url hidden somehow?

Yep, that's a good idea.


> I can't think of exactly what else I would do to improve it right now

I've already got some more code in place that I'm testing right now which 
does aggregation of matching result profiles. That is, if a request results 
in the same call profile, the timings are aggregated into min/average/max. 
Really neat :)

Thanks for the feedback!


    Richard