Hello v8 folks, I filed this Chromium issue (https://code.google.com/p/chromium/issues/detail?id=557466) a couple days ago, but I attended the Chrome Dev Summit in Mountain View yesterday and was directed to this list for V8-related internal issues. So here I am!
I've been poking around at the background script streaming thread logic for the past week or so to see if I could increase the amount of async script parsing that we do off the main thread when loading facebook.com (disclaimer: I work for Facebook). Facebook sends a pretty sizable pile of JS down to the browser on page load, most of which is not very hot (e.g. in Safari, ~87% of the ~6500 executed functions never make it past the bytecode interpreter). When running Instruments on a trunk release build of Chromium I see ~20% of overall execution time spent parsing JS and generating code on the main thread while I see < 1% CPU time spent on the script streaming thread. According to some console-fu, it seems that ~70% of the script tags in the document on home.php are marked with the async attribute, so given how much time we spend on the main thread parsing JS I figured that there should also be plenty of work for the script streaming thread. I think I've improved utilization of the script streaming thread slightly with a few tweaks including: (1) reducing the small script threshold from 30 KB, which was preventing the background thread from even attempting to parse many scripts. (2) forcing the script streaming thread to perform eager rather than lazy parsing in hopes of reducing the total amount of parsing happening on the main thread. (3) allowing the main thread to retry posting parsing tasks to the background thread at a later time if the background thread is currently busy. These tweaks may have moved the needly slightly (I'm not 100% convinced since I haven't done any rigorous measurements), but I'm still seeing a suspiciously high amount of CPU time spent on the main thread parsing JS along with a suspiciously low amount of parsing activity on the background thread when looking at both Instruments profiles and Chrome traces recorded with chrome://tracing. In a simplified test page that tries loading multiple async scripts concurrently, I noticed that even when the script streaming thread parses a script, it then sends a task back to the main thread which then proceeds to do a bunch more lazy parsing! I realize that the background thread isn't allowed to generate code so it must give it back to the main thread, but this additional parsing time surprised me. I tried adding some more tracing events to get a better picture of what's going on at various times. For example, it seems like we receive JS scripts on the main thread in clusters rather than in an evenly spaced manner which, due to the fact that the background thread synchronously parses a single JS file at a time, causes the other scripts to have to wait to be parsed. A pool of worker threads might help some, but probably won't be sufficient on devices with low core counts. It might be better if we could incrementally parse JS and multiplex multiple JS files on one or two parsing threads. Incremental parsing sounds like a big, potentially invasive effort though. I realize that forcing more parsing onto the background thread could cause adverse side effects related to page interactivity, but I'd like to be able to experiment with different amounts of parsing on either the main thread or the background thread. I was wondering, given the steps I've taken, if I've missed or misunderstood anything. I think off-main-thread parsing is a great idea, so any help debugging/understanding/improving the script streaming thread would be very much appreciated :-) And while the script streaming stuff was just the first weird thing I stumbled across, given the importance of parsing in general on complex, JS-heavy sites like Facebook, any additional info related to how V8 does parsing and how sites might be able to take advantage of that would be very helpful. Thanks! -Mark Hahnenberg -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
