[Webkit-unassigned] [Bug 25503] Add instrumentation framework to WebCore

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25503





------- Comment #6 from jamesr at google.com  2009-05-11 15:42 PDT -------
(In reply to comment #3)
> Some general feedback (I didn't read Sam's yet)
> 
> * I'm not sure I like the pairing of a specific start signal
> ("recalcStyleStarting") with a generic end signal ("finished"). Seems like it
> would be good to force pairing, even if just to assert that they are correctly
> paired.
> * Rather than hard-coding all the categories in method names, why not make it
> extensible:
> 
> analysisClient()->start("parsing");
> analysisClient()->end("parsing");
> 
> Then you just need a hash to store data in on the collection side.

The advantage of having separate callbacks is that the instrumentation points
can be easily parameterized to keep data around beyond simple start/end
timestamps. For example, the paint instrumentation point could also have the
size of the bounding box being painted.

> 
> * Why have WebAnalysisClient in WebKit? Seems like the mechanics of data
> collection and analysis will be the same for every platform, so should be in
> WebCore. Then what you export via WebKit is:
> i) a way to turn it on and off
> ii) a way to get at the raw data (e.g. for a UI visualizer) or summary data?
> I think WebCore should also have code to dump the output. You could use a log
> channel for output, maybe.
> 

The DRT aggregation is fairly simple and could potentially apply to all
platforms, but it's more intended as an example of a use of this data and not
the only one.   We've experimented with tools that keep entire trace trees
around and found that the data is quite interesting but also very large and
probably doesn't make sense to keep around in WebCore proper.  In the other
extreme, the Android folks have experimented with instrumentation points that
do nothing except log to one of their system logs to keep the observer effects
down while understand perf regressions.  I think it makes sense to keep the
instrumentation itself very generic for now and figure out exactly what sort of
processing should be in WebCore vs the platform layer as times goes on.  Does
that approach seem good to you?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.