Sorry – you're absolutely right. This is what happens when I type things that should really be copy&pasted. The actual command I ran was:
for f in ~/js/*; do echo $f; out_after/x64.release/d8 --cache=parse --trace_parse $f | grep 'parsing script'; done From: Marja Hölttä <[email protected]<mailto:[email protected]>> Date: Wednesday, December 10, 2014 at 3:34 AM To: Ian Cullinan <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "McCormick, Kevin" <[email protected]<mailto:[email protected]>> Subject: Re: Support lazy parsing of inner functions (issue 641283003 by [email protected]<mailto:[email protected]>) But but... "d8 --cache=code --trace_parse" doesn't even use the parse cache, it uses the code cache! Why are you running with --cache=code? On Tue, Dec 9, 2014 at 10:55 PM, Cullinan, Ian <[email protected]<mailto:[email protected]>> wrote: (Emailing directly since mail sent by codereview.chromium.org<http://codereview.chromium.org> for @amazon.com<http://amazon.com> addresses gets stuck in spam filters. My apologies if you get this twice.) > Q: I wonder whether we need to / should modify the "preparse data". Would > it be > better to keep it as is, so that it just contains the positions of the >lazy > top-level functions and no identifiers? (I don't know the answer.) Adding the identifiers to the preparse data gets us a pretty big win on warm parsing times. I don't have access to morejs so I can't try that, but what I have been doing is running `d8 --cache=code --trace_parse` with some popular JavaScript files from the web and looking at how long parsing takes with and without the preparse data, with and without my change (on my desktop, times in milliseconds, median of five runs): before after cold warm cold warm http://connect.facebook.net/en_US/all.js 8.2 7.9 5.1 0.7 http://[1]/analytics.js 1.9 1.7 1.7 0.5 http://b.scorecardresearch.com/beacon.js 0.1 0.02 0.1 0.02 http://a.disquscdn.com/embed.js 1 0.04 1 0.04 http://www.google-analytics.com/ga.js 3 2.8 2.6 0.6 http://[2]/jquery/1.7.2/jquery.min.js 5.8 5.6 4.1 0.9 http://[3]/pagead/js/lidar.js 3.6 3.3 2.8 0.7 http://[3]/pagead/osd.js 3.1 2.9 2.5 0.6 http://platform.twitter.com/widgets.js 2.5 0.25 2.5 0.25 [1] www.google-analytics.com<http://www.google-analytics.com> [2] ajax.googleapis.com/ajax/libs<http://ajax.googleapis.com/ajax/libs> [3] pagead2.googlesyndication.com<http://pagead2.googlesyndication.com> As you can see, it's the same or better in every case (0-38% speedup cold, 0-91% speedup with the preparse data). It's a particularly large win on modern JavaScript libraries like jQuery which make extensive use of closures to avoid polluting the global scope. Here's the numbers for the size of the preparse data (in bytes): before after http://connect.facebook.net/en_US/all.js 20 15260 http://[1]/analytics.js 20 14500 http://b.scorecardresearch.com/beacon.js 60 76 http://a.disquscdn.com/embed.js 340 468 http://www.google-analytics.com/ga.js 20 23300 http://[2]/jquery/1.7.2/jquery.min.js 20 17820 http://[3]/pagead/js/lidar.js 20 21384 http://[3]/pagead/osd.js 20 18744 http://platform.twitter.com/widgets.js 1120 1560 The extra preparse data is only significant in the cases where it's buying us a large speedup. >https://codereview.chromium.org/641283003/ -- -- 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.
