[Webkit-unassigned] [Bug 150689] Web Inspector: Handle or Remove ParseHTML Timeline Event Records

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Nov 2 15:25:43 PST 2015


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

--- Comment #8 from Joseph Pecoraro <joepeck at webkit.org> ---
(In reply to comment #6)
> (In reply to comment #5)
> > I think the only time it would be worth seeing is if it were unusually
> > large. Perhaps you should test this on the all-in-one HTML5 spec page.
> > 
> > http://www.w3.org/TR/html5/single-page.html

Reloading this page there were:

  - 805 ParseHTML records
  - Ranging from 0.01ms - 9.23ms accounting for children
  - The longest ParseHTML records were solely parsing scheduling a style recalc / invaliding layout
  - 43.5% were <= 1ms

Reloading cnn.com there was:

  - >11900 ParseHTML records
  - Ranging from 0.00ms - 8.50ms
  - The longest being the 2nd record received!
  - 99.9% were <= 1ms

Reloading apple.com there was:

  - 34 ParseHTML records
  - Ranging from 0.00ms - 2.39ms
  - Again the longest were the first few records received
  - 94% where <= 1ms

As suspected, this is only really apparent in the case of the very very large document. For most pages, and certainly after initial page load, parse time becomes insignificant. The only advantage I can see to keeping these records is that it, when debugging page load we could account for a few ms of "Other" time in some frames for Rendering Frames timelines (as right now this is contributing to Other) but it is still a small chunk.

(In reply to comment #7)
> I'm pretty sure these ParseHTML records will always be small, given how the
> parser handles incoming data in small chunks from the network. It also
> starts and stops as it hits <script> and <style> tags.

Yep, that appears to be the case.

--

I vote dropping it, I'll put up a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151102/042809a3/attachment.html>


More information about the webkit-unassigned mailing list