1152886 - Add timeline markers to trace document.write calls

Status: RESOLVED INVALID

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

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

document.write messes up all kinds of stuff and stops all kinds of pipelining. We should trace it and surface it in the perf timeline.

Comment 1

[Henri Sivonen (:hsivonen)]

(In reply to Nick Fitzgerald [:fitzgen] from comment #0)
> document.write messes up all kinds of stuff and stops all kinds of
> pipelining. We should trace it and surface it in the perf timeline.

There are really three cases:

 1) Any non-async, non-defer script *might* call document.write, so even if it's not called, there's some complexity involved in order to prepare for the *possibility*. I suppose you could try to measure the overhead of a non-async script vs. an async script for parsing purposes, but I expect the overhead to be negligible and not worth bothering Web devs about.

 2) A script (has to be non-async, non-defer) calls document.write (potentially multiple times) and the calls taken together end up writing a balanced subtree. In this case, the only perf badness is that the parsing happens on the main thread and can't be overlapped with the main thread on a different CPU core. Unclear if this is worth bothering Web devs about.

 3) The document.writes are not balanced. Look for nsContentUtils::ReportToConsole after "if (speculationFailed) {" in nsHtml5StreamParser::ContinueAfterScripts. This is worth whining about for sure. (Already whined to console.) I suppose you could report how much wall clock time the parser thread used for work that got thrown away, but that doesn't fit a timeline, since it's overlapped with the main thread.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

What if we just trace the initial HTML parsing if it happens on the main thread, and since markers can have arbitrary metadata, we attach a why-we-parsed-html-on-the-main-thread string?

Comment 3

[Henri Sivonen (:hsivonen)]

(In reply to Nick Fitzgerald [:fitzgen] from comment #2)
> What if we just trace the initial HTML parsing if it happens on the main
> thread, and since markers can have arbitrary metadata, we attach a
> why-we-parsed-html-on-the-main-thread string?

The question seems to assume parser behaviors that are not there.

Markup that came from the network/file channel is parsed off-the-main thread. If there are bad (case #3 in my previous comment) document.writes, markup from the network/file channel that is logically after the script that made the bad document.write call(s) is parsed again (and again if there are yet more bad document.writes later).

Markup that came from strings passed to document.write is always parsed on the main thread.

In both cases, the parser outputs a sequence of operations to be performed in order to construct the DOM and those operations are performed on the main thread.

So you can put DOM construction and document.write parsing in the main-thread timeline. Additionally, if there are bad document.writes, you could attach info about how much off-the-main-thread waste that particular document.write caused (by reporting the time the parser thread spent such that the work was thrown away).

Comment 4

[Victor Porof [:vporof][:vp]]

Triaging. Filter on ADRENOCORTICOTROPIC (yes).

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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