1418279 - No "Parse HTML" data in the "Performance" tab of dev tools

Status: UNCONFIRMED

(Core :: DOM: HTML Parser, enhancement)

Description

[garmash.nikolay]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

1. Record a page load in the "Performance" tab.
2. Filter everything except "Parse HTML" and "Parse XML"


Actual results:

Nothing is left in the list


Expected results:

Timing for HTML parsing is shown in the list

Comment 1

[Greg Tatum [:gregtatum]]

This won't be fixed in the current performance tool, but probably requires investigation to see what our support looks like in the profiler in general. I'm leaving this open for now.

Comment 2

[Julien Wajsberg [:julienw]]

Looking at a recent profile, I don't see anything related to HTML parsing readily available. I'm keeping this bug open for now.

Comment 3

[Julien Wajsberg [:julienw]]

I believe the work here is to add some well-named pseudo frame labels with the "relevant for js" flag.

Comment 4

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I see that the parsing happens in an "HTML5 Parser" thread, so adding "parser" to the thread list in about:profiling will at least sample it, e.g.: https://share.firefox.dev/3KN6sVC

But indeed there are very few labels and markers, so it could be useful to add more informative ones.

I'm forwarding this bug to the parser component, they would know best where to add these labels&markers, and what kind of information would be useful to expose.
Use AUTO_PROFILER_LABEL_RELEVANT_FOR_JS to add labels that are relevant for JS. E.g., here's one in layout.
Here are the marker docs.
Please contact me if you'd like any help with these.

Comment 5

[Henri Sivonen (:hsivonen)]

I don't have a good idea of what the profiler wants to know and why. Here are some remarks of what might be of interest:

The "HTML5 parser" thread runs the tokenization and the tree builder algorithm (to the point of deciding what needs to go into the DOM without yet putting it there) for content that arrives from streams (i.e. http(s), file, srcdoc, XHR in HTML mode, but not innerHTML or DOMParser). Apart of the thread being attributable as a catch-all to HTML parsing, it might be of interest to look at the performance-relevant console messages and also put some of those on the profiler timeline.

You might want a marker for encoding speculation failing. (Discovered on the parser thread.)

And for speculation across document.write failing. (Discovered on the main thread.)

Other things of interest:

The parse starting. (Discovered on the main thread.)

The parser thread reaching the end of the stream. (Discovered on the parser thread. Can occur multiple times if speculation fails.)

The main thread reaching the end of the parse from the DOM perspective. (Discovered on the main thread.)

Time spent parsing document.write-originating HTML: This method. And this one.

Time spent on the main thread building the DOM (for non-document.write purposes) in response to what the parser thread says: This method.

Comment 6

[Henri Sivonen (:hsivonen)]

Both for time spent parsing document.write-originating data and for time spent building the DOM, the profiler label scope should probably exclude the script execution time.

Comment 7

[Henri Sivonen (:hsivonen)]

Are the two previous comments enough for someone on the profiler team to take this?

Comment 8

[Henri Sivonen (:hsivonen)]

For tracking HTML parsing time not from a stream, the methods of interest are these:
https://searchfox.org/mozilla-central/rev/408eac3ccaea2d35b00706925d4d944803e19aba/parser/html/nsHtml5OplessBuilder.h#27-28

Comment 9

[Henri Sivonen (:hsivonen)]

XML fragment parsing.

XML parse starting. (I think; not sure.)

XML parse ending.

Comment 10

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Removing my NI, but this could still be done (by the parsing team and/or the profiler team) when time permits.

Comment 11

[Julien Wajsberg [:julienw]]

Looking at a profile, I feel like this profiler label could have a simplified name and a good category and subcategory: https://searchfox.org/mozilla-central/rev/380fc5571b039fd453b45bbb64ed13146fe9b066/parser/html/nsHtml5TreeOpExecutor.cpp#563. This would already go a long way.

Comment 12

[Henri Sivonen (:hsivonen)]

(In reply to Julien Wajsberg [:julienw] from comment #11)

Looking at a profile, I feel like this profiler label could have a simplified name and a good category and subcategory: https://searchfox.org/mozilla-central/rev/380fc5571b039fd453b45bbb64ed13146fe9b066/parser/html/nsHtml5TreeOpExecutor.cpp#563. This would already go a long way.

I'd appreciate it if someone working on the profiler who knows the category conventions could post a patch for that.