[Webkit-unassigned] [Bug 55011] Fragment parsing does not need to use HTMLSourceTracker

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Eric Seidel <eric at webkit.org>  2011-02-23 03:28:26 PST ---
(In reply to comment #10)
> (In reply to comment #4)
> > The reason why we don't see the same thing with PerformanceTests/Parser/html-parser.html, is that html-parser and tiny-innerHTML are totally different benchmarks.
> > 
> > tiny-innerHTML doesn't really even make sense as a benchmark, and was only created to model Peacekeeper (which I believe to be a broken benchmark!).  tiny-innerHTML (and peacekeeper) are just taking very tiny numbers (the time it takes to innerHTML a single text node) and multiplying them by very very large numbers.  In the real world, we don't care if innerHTML of a single text string takes .5 miliseconds or .2 miliseconds. :)  Both are well beyond what any website uses.
> > 
> > html-parser.html on the other hand is a very useful benchmark.
> 
> I don't think we should discount the prevalence of repeated calls to innerHTML as a content generation technique. For instance, here's a benchmark from quirksmode comparing DOM API to innerHTML for creating a 50x50 table:
>
> http://www.quirksmode.org/dom/innerhtml.html

Sure.  It's just that the bechmark does 100k innerHTMLs, each of which takes only 0.056 milliseconds!  The fact that we're fretting about reducing each to 0.026 milliseconds is silly IMO. :)  Shaving 0.03ms per innerHTML does not seem worth our time (which is why I continue to believe the benchmark is crap).

It's more interesting that we can parse an entire 5MB HTML file in 800ms, and continuing to make that number smaller seems useful.

> One interesting thing this benchmark demonstrates is that, especially in IE, innerHTML is significantly faster than using DOM API. It seems likely that at least some content authors have used this as a rule of thumb and designed pages that rely on innerHTML to generate dynamic content.

Cool.  I'll take a look at http://www.quirksmode.org/dom/innerhtml.html and see if there is anything useful there.

> That convinces me that improving fragment parsing performance is an important task regardless of our opinions of Peacekeeper as a benchmark.

Yes, but peacekeeper (or at lest tiny-innerHTML) does not actually test fragment parsing performance since total time to parse the example fragment is counted in microseconds. :)

We could continue to improve our longer-running parser benchmarks and probably see further improvements to the PLT score (which is also basically useless due to being too small a set these days) and other "more real" pages.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.