Open Bug 707391 Opened 13 years ago Updated 2 years ago

Categorize time away from event loop

Categories

(Core :: General, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: taras.mozilla, Assigned: jrmuizel)

References

Details

(Whiteboard: [Snappy:p2])

It is not useful to know that we are spending a lot of time in event loop unless know where that time is going. Would be great to be able to generate telemetry data to report proportion of time spent in selector-matching, reflows, js execution, other blocking APIs. 
This would help us justify invasive solutions like js green threads(bug 384412).

Will Benoit's profiler be sufficient for this? My goal would be to get an about:memory style report of exactly where time was spent(except snappy would need a temporal dimension).
Assignee: nobody → jmuizelaar
Broken record: with the circular-queue support now in jprof, it's fairly easy to trigger it on "long" event-loop instances and save the samples from the firing of the event until when it comes back to the loop (as an example).  

Then when about:snappy (or whatever) is (re)loaded, spawn jprof to process the data thus far and dump it to an HTML file, and then it can be loaded into a tab, or what have you.  The downside is that it's a profile - you have to be able to read profiles to use it.  This might be of more use for the equivalent to an "about:snappy?profile" link off about:snappy.  

With minor mods, jprof could select out individual instances for profiling - i.e. if about:snappy is showing you data (such as a histogram), you could select a bin of the histogram and pull up profiling data for just those instances (jprof can filter which sets of samples are included, and could easily be extended to include that).  Or if it's showing a timeline, it could profil a specific event-loop instance.
It's not a matter of using a specific backend, it's the outcome I'm interested in. If we can categorize where our event loop time is spent via telemetry in the wild with jprof, that's good.
This sounds like exactly what BenWa is working on in bug 653703.
(In reply to Ted Mielczarek [:ted, :luser] from comment #3)
> This sounds like exactly what BenWa is working on in bug 653703.

Jeff proposed using that as a backend. This needs to be coarse grained so we can telemetry it.
Depends on: 653703
FYI, in bug 712224 I have patches for jprof that make it generate "cleopatra" output that BenWa's visualization tool can process.
Whiteboard: [Snappy] → [Snappy:p2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.