Closed Bug 1152416 Opened 10 years ago Closed 2 years ago

Add timeline markers to trace page load tasks

Categories

(DevTools :: Performance Tools (Profiler/Timeline), defect, P3)

defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: fitzgen, Unassigned)

References

Details

(Whiteboard: [devtools-platform])

:smaug tells me parsing HTML is done off main thread, however the devtools performance tool's timeline events are generally about things that happen on the main thread. (We would like to add support for other threads eventually, but the waters get murkier about what is correlated with a specific tab we are recording and we don't have UI to show what thread a traced task is on yet). So, what things should we trace? * :smaug tells me DOM creation happens on the main thread, that sure seems like a good candidate for tracing. * We should probably trace all document.write calls, because they just suck in general. * What else?
ni? for ideas of things we should be tracing
Flags: needinfo?(hsivonen)
Flags: needinfo?(bugs)
DOM creation might be something to trace. That is when the data from the parser thread is processed on the main thread.
Flags: needinfo?(bugs)
(In reply to Nick Fitzgerald [:fitzgen] from comment #0) > * :smaug tells me DOM creation happens on the main thread, that sure seems > like a good candidate for tracing. Filed bug 1152887 > * We should probably trace all document.write calls, because they just suck > in general. Filed bug 1152886
Summary: Add timeline markers to trace page load tasks → [marker] Add timeline markers to trace page load tasks
(In reply to Nick Fitzgerald [:fitzgen] from comment #0) > So, what things should we trace? On the main thread: * DOM construction. (I.e. time spent in nsHtml5TreeOpExecutor::RunFlushLoop() plus time spent in nsHtml5TreeOpExecutor::FlushDocumentWrite() minus time spent in nsHtml5Parser::ParseUntilBlocked().) * Time spent parsing document.written content. (I.e. time spent in nsHtml5Parser::Parse(const nsAString& etc.) plus time spent in nsHtml5Parser::ParseUntilBlocked() minus time spent in nsHtml5TreeOpExecutor::FlushDocumentWrite().) Off the main thread: * Time spent parsing such that the operations were not thrown away (not speculating or speculation successful). * Time spent parsing such that the operations were thrown away (speculation failed). The off-the-main-thread time overlaps the main thread time on multi-core CPUs and won't make sense as part of the timeline, though.
Flags: needinfo?(hsivonen)
(In reply to Henri Sivonen (:hsivonen) from comment #5) > (In reply to Nick Fitzgerald [:fitzgen] from comment #0) > > So, what things should we trace? > > On the main thread: > > * DOM construction. (I.e. time spent in > nsHtml5TreeOpExecutor::RunFlushLoop() plus time spent in > nsHtml5TreeOpExecutor::FlushDocumentWrite() minus time spent in > nsHtml5Parser::ParseUntilBlocked().) Minus time spent executing scripts, of course.
Whiteboard: [devtools-platform]
No longer depends on: 1218078
Triaging. Filter on ADRENOCORTICOTROPIC (yes).
OS: Mac OS X → Unspecified
Priority: -- → P3
Hardware: x86 → Unspecified
Summary: [marker] Add timeline markers to trace page load tasks → Add timeline markers to trace page load tasks
Product: Firefox → DevTools
Severity: normal → S3

This report is related to the old DevTools Profiler.
The Performance panel now points to the new Firefox profiler available at profiler.firefox.com
Closing as Invalid bug

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.