Bug 111247
| Summary: | Threaded HTML Parser should parse the first chunk on the main thread | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | abarth, ahmad.saleem792, cdumez, tonyg |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 111645 | ||
Eric Seidel (no email)
Threaded HTML Parser should parse the first chunk on the main thread
We may have to be slightly more careful about which bool we check, as we'll be in threaded mode w/o having started a background parser yet. But right before we would yield, we just pass our Tokenizer and HTMLToken off to a newly started background parser and then yield the main thread.
I suspect this should be a win for small (<1k token) documents which can be parsed in a single chunk.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Barth
Yeah, this seems like it should be faster. We should fine a way to test the performance before landing it. The HTML spec parsing benchmark probably isn't the right thing since it's a big document. Maybe we should measure with telemetry's top25 page set?
Eric Seidel (no email)
Yes, I think Telemetry will be more interesting here. Something with lots of small resources should hit this?
Then again, now that I think about it, I'm not sure small pages even show up in parse time given all the rest of the loader overhead. I suspect what this would actually make faster is the layout tests. :)
Ahmad Saleem
@Chris - Do we have this or we can close this and blocker bugs in META bug?
Chris Dumez
We are not using a multi-threaded HTML parser.