5 ms·

Pretty sure all WebKit-based browsers (including chrome) do this. I'd guess they block if needed, but I'm not sure.

• esprehn 9y ago
  fwiw WebKit never turned on the threaded html parser (and deleted it after the fork [1]) and Blink removed it a bit ago too [2]. In Chrome we measured it across a number of sites and found that the time saved from background tokenization wasn't benefiting real world content enough to justify the cost and that in some situations it actually made things worse. That's not to say Servo shouldn't try it of course! Part of having a healthy multi-browser ecosystem is each browser trying lots of ideas and coming up with new solutions to problems that were encountered in other implementations. [1] http://trac.webkit.org/changeset/162260/webkit http://trac.webkit.org/changeset/162260/webkit (the number cited here is a joke :P) [2] https://groups.google.com/a/chromium.org/forum/#!topic/loading-dev/_cXkjQ0-L_E https://groups.google.com/a/chromium.org/forum/#!topic/loadi... (see also the design doc linked from the email)
  • krzat 9y ago
    I guess one of goals of Rust is to make these sort of optimisations viable (compiler provides safety nets). Will be nice to see what they can do.
    • hsivonen 9y ago
      Gecko has had off-the-main thread HTML parsing since Firefox 4. Docs: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_... WebKit/Blink put fewer parts of the HTML parser off the main thread, so negative results should not be taken to apply to more comprehensive approaches.
  • ibotty 9y ago
    I don't get the joke. Were these defines never used? Did the commit removing the threaded html parser happen before?
    • bla2 9y ago
      I'd wager the feature required fewer than 8.8 million lines of code :-)