Just thought I'd make this important item of note: most of those sites have a *lot* more variables than just parse/execution times.
- Wikipedia extensively uses progressive enhancement and does *all* their rendering server-side outside of the few interactive components involved (e.g. editing, search). Benchmarks are going to be more about HTML parsing speed than JS (and HTML parsing is considerably more difficult). - Facebook and Google use JS extensively, but they have so many assets in general to load that they defer most of their script loading to the last moment possible, which can make load times seem much faster than they really are (as in, the `onload` event fires before the page is fully loaded conceptually). They split their bundles automatically, they both primarily rely on binary data transmission (especially on mobile), and Facebook in particular rolled their own auto-batching framework called GraphQL, just to effectively manage the large amount of requests they require (to avoid overloading both their servers and their clients). Baidu and friends have a similar story. - Reddit is a curious case, and probably should be reported. It's slow to load on all browsers, though, but that huge jump between Electron v0.27.1 and v0.28.1 (plus the presence of several outliers and the fact it hasn't fully come back down) signifies a non-deterministic perf regression in the loading pipeline that hasn't been fully resolved. The V8 version is the same on both, so that can be ruled out. - If you remove Reddit, Yahoo, and QQ.com, the only significant change was in Electron v1.0.1 to v1.1.1, shifting from V8 v4.9 to V8 v5.0. V8 v5.0 brought a lot of ES5 perf and stability improvements. (It also brought those sites closer to back in line with less variability.) Yes, execution time does have an impact, but engines already had most of the necessary infrastructure in place to avoid too much issue - engines can even inline proxy calls now, and they didn't have to reinvent their internal structure to do so. (V8's massive Ignition/TurboFan/CodeStubAssembler restructuring was independent of ES6, and was just for bringing a sense of performance predictability and easier code reasoning, without having to go through tons of low-level boilerplate to do so. ES6 was a partial catalyst, but internal maintenance issues were a similar factor.) ----- Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Wed, Jan 17, 2018 at 9:51 PM, kai zhu <kaizhu...@gmail.com> wrote: > tldr - i ran a crude experiment which suggests es6 doesn’t affect > v8-engine’s intrinsic parsing-performance much to significantly impact > webpage load-times (can someone verify that v8 v4.1.0.21 does NOT support > es6 to confirm i have datapoint for @ least one non-es6 engine?). > > > so i did something similar to what @kdex suggested, and ran a script testing > onload performance with each version of electron-browser for alexa's top 10 > global sites. then plotted the datapoints of onload-time-performance vs. > v8-engine versions. there doesn’t seem to be any obvious conclusions to draw > from the data. > > the visualized results are available @ > https://kaizhu256.github.io/node-electron-onload-test/result.html. > > you can reproduce the experiment with the following script: > > ```javascript > /* > lib.electron_onload_test.js > > this function will test the onload performance of the given url > > # example usage 1: > mkdir -p node_modules > npm install electron-lite --electron-version=v1.1.1 > url=https://www.google.com node_modules/.bin/electron > lib.electron_onload_test.js > > > > # example usage 2: > printf "" > "$HOME/electron.log" > rm -f /tmp/electron.done > for vv in \ > v0.24.0 \ > v0.25.1 \ > v0.26.1 \ > v0.27.1 \ > v0.28.1 \ > v0.29.1 \ > v0.30.1 \ > v0.31.1 \ > v0.32.1 \ > v0.33.1 \ > v0.34.1 \ > v0.35.1 \ > v0.36.1 \ > v0.37.1 \ > v1.0.1 \ > v1.1.1 \ > v1.2.1 \ > v1.3.1 \ > v1.4.1 \ > v1.5.1 \ > v1.6.1 \ > v1.7.1 > do > mkdir -p node_modules > npm install electron-lite --electron-version="$vv" > # https://en.wikipedia.org/wiki/List_of_most_popular_websites > for uu in \ > https://www.google.com \ > https://www.youtube.com \ > https://www.facebook.com \ > https://www.baidu.com \ > https://en.wikipedia.org/wiki/Main_Page \ > https://www.google.co.in \ > https://www.yahoo.com \ > https://www.reddit.com \ > http://www.qq.com \ > https://world.taobao.com > do > for ii in 1 2 3 4 5 6 7 8 9 10 > do > (url="$uu" node_modules/.bin/electron > lib.electron_onload_test.js 2>&1 | \ > tee -a "$HOME/electron.log") & > for ii in \ > 1 2 3 4 5 6 7 8 9 10 \ > 11 12 13 14 15 16 17 18 19 20 \ > 21 22 23 24 25 26 27 28 29 30 > do > sleep 1 > if [ -f /tmp/electron.done ] > then > break > fi > done > rm -f /tmp/electron.done > killall Electron electron 2>/dev/null > sleep 1 > done > done > done > */ > > > > /*jslint > bitwise: true, > browser: true, > maxerr: 8, > maxlen: 96, > node: true, > nomen: true, > regexp: true, > stupid: true > */ > (function () { > 'use strict'; > var local; > local = {}; > // inject onload timer > if (typeof window === 'object') { > local.now = Date.now() - 1000; > window.addEventListener('load', function () { > // wait 1000 ms for async loaders to finish > setTimeout(function () { > console.error('onLoadTime ' + (Date.now() - local.now)); > }, 1000); > }); > return; > } > if (!process.versions.electron) { > return; > } > // npm install electron-lite > if (!require('fs').existsSync('node_modules/electron-lite') || > process.env.npm_config_electron_version) { > require('child_process').spawnSync('mkdir', [ > '-p', > 'node_modules' > ], { stdio: ['ignore', 1, 2] }); > } > // wait for electron to init > (process.versions.electron >= '0.35' > ? require('electron').app > : require('app')).once('ready', function () { > // init local > local = { frame: false, height: 768, width: 1024, x: 0, y: 0 }; > // init browserWindow; > local.BrowserWindow = (process.versions.electron >= '0.35' > ? require('electron').BrowserWindow > : require('browser-window')); > local.browserWindow = new local.BrowserWindow(local); > // title > local.browserWindow.on('page-title-updated', function (event, title) > { > if (event && title.indexOf('onLoadTime ') !== 0) { > return; > } > local.tmp = JSON.parse(JSON.stringify(process.versions)); > local.tmp.arch = process.arch; > local.tmp.onLoadTime = title.split(' ')[1]; > local.tmp.platform = process.platform; > local.tmp.timestamp = new Date().toISOString(); > local.tmp.url = process.env.url; > local.result = {}; > Object.keys(local.tmp).sort().forEach(function (key) { > local.result[key] = local.tmp[key]; > }); > console.log(); > console.log(title + ' - ' + local.result.url); > console.log(JSON.stringify(local.result)); > console.log(); > require('fs').writeFileSync('/tmp/electron.done', new > Date().toISOString()); > process.exit(0); > }); > /* jslint-ignore-begin */ > require('fs').writeFileSync('/tmp/electron.webview.html', '\ > <style>\n\ > body {\n\ > border: 1px solid black;\n\ > margin: 0;\n\ > padding: 0;\n\ > }\n\ > </style>\n\ > <webview\n\ > id="webview1"\n\ > preload="' + __filename + '"\n\ > src="' + process.env.url + '"\n\ > style="border: none;height: 100%;margin: 0;padding: 0;width: 100%;"\n\ >>\n\ > </webview>\n\ > <script>\n\ > (function () {\n\ > var local;\n\ > local = {};\n\ > local.webview1 = document.querySelector("#webview1");\n\ > local.webview1.addEventListener("console-message", function (event) {\n\ > if (event.message.indexOf("onLoadTime ") === 0) {\n\ > console.log(event.message);\n\ > document.title = event.message;\n\ > }\n\ > });\n\ > }());\n\ > </script>\n\ > '); > /* jslint-ignore-end */ > // open url > local.url = 'file:///tmp/electron.webview.html'; > (local.browserWindow.loadURL || local.browserWindow.loadUrl).bind( > local.browserWindow > )(local.url, { > userAgent: local.modeBrowserTest === 'scrape' && > 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 ' + > '(KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36' > }); > }); > }()); > ``` > > > On Jun 23, 2017, at 11:32 AM, kdex <k...@kdex.de> wrote: > > For what it's worth, if you're only interested in v8, have a look at the > "Performance" panel in DevTools. You can inspect "Parse" and "Compile" time > by > in the Bottom-Up view, given that you've enabled `Timeline: V8 Runtime Call > Stats on Timeline` in the hidden options of`Experiments`. > > On Friday, June 23, 2017 6:19:20 AM CEST kdex wrote: > > First of all, ECMAScript requires an environment, which may or may not > be > a browser. So it might not necessarily make sense to assume "web pages" > or > browsers in the first place. > > > wrong. all proposals eventually end up creeping into “web pages” or > browsers, either by adventurous coders or frameworks that lack clear > boundary separation between client / server code. > > > "Wrong"? It seems that you are confused about how the language works. Feel > free to read this[1] section of the language specification. > > both parse-time and [first-run] compile-time. the intent is to vet most > language-changing proposals for their impact on initial webpage “freeze" > due to increased parse-time and compile-time complexity. > > > AFAIK, ECMAScript doesn't force implementers to "compile" anything, i.e. run > a native code generation step as popular engines do. As you're more or less > dealing with engine-specifics here, you're leaving ECMAScript territory, so > this would likely be the wrong mailing list. The same really applies to > parse time; the language specification doesn't specify a parser, but a > grammar. The performance really depends on how the parser is implemented, > as well as on the type of grammar/amount of look-ahead needed. > > hypothetically, can an enterprising individual provide a graph of 1) > combined-time to parse-and-compile jquery vs 2) browser-version-history > for > desktop chrome and firefox since 2015? > > > I'm reading this as "Could I create a graph that plots a specific browser > version on the x axis and parse time + compile time on the y axis?", and the > answer would be 'yes'. As a side note, do note that *absolute* time is a > terrible metric here, as device specs can differ by a lot and aren't > actually representative for anything but themselves. Relative times should > be preferred. Nonetheless, if you want to gather this data, you can look up > the respective engine versions that were used for the browser versions in > question, edit their source to measure the intervals that you find > interesting and then compile and run them. > > yes, relevant proposals should consider the implementation-specific > compile-time of engines > > > Should they really? If a parser is badly implemented, it should be fixed, > not worked around. Again, it's really a question of the type of grammar and > the type of parser used. The features involved are second nature, at least > for the metrics you're trying to measure. > > as an added precaution against breaking the web. > > > This is not "breaking the web", because we're not talking about websites > that worked once, but don't work anymore, given the same code. We're simply > talking about "parse and compile" performance here. > > [1] https://tc39.github.io/ecma262/#sec-overview > > On Friday, June 23, 2017 5:37:17 AM CEST kai zhu wrote: > > First of all, ECMAScript requires an environment, which may or may not > be > a > browser. So it might not necessarily make sense to assume "web pages" or > browsers in the first place. > > > wrong. all proposals eventually end up creeping into “web pages” or > browsers, either by adventurous coders or frameworks that lack clear > boundary separation between client / server code. > > is "load time" equivalent > to "parse time"? Is it "compile time"? Is it both? > > > both parse-time and [first-run] compile-time. the intent is to vet most > language-changing proposals for their impact on initial webpage “freeze" > due to increased parse-time and compile-time complexity. > > Could you state your question more precisely, please? > > > hypothetically, can an enterprising individual provide a graph of 1) > combined-time to parse-and-compile jquery vs 2) browser-version-history > for > desktop chrome and firefox since 2015? > > Anything else [compile-time] is mostly implementation- > specific and thus varies from engine to engine. > > > yes, relevant proposals should consider the implementation-specific > compile-time of engines as an added precaution against breaking the web. > > On 22 Jun, 2017, at 8:20, es-discuss-requ...@mozilla.org wrote: > > From: kdex <k...@kdex.de> > Subject: Re: are there metrics on how es6 and future proposals affect > javascript load-time for webpages? Date: 22 June, 2017 8:20:16 HKT > To: es-discuss@mozilla.org > > > I don't think that this is a well-defined question. Is "load time" > equivalent to "parse time"? Is it "compile time"? Is it both? Is it > something else? Are we talking about engines that don't generate native > code and thus maybe "interpretation time"? What are we measuring when > you > say "JavaScript load time"? > > First of all, ECMAScript requires an environment, which may or may not > be > a > browser. So it might not necessarily make sense to assume "web pages" or > browsers in the first place. > > Aside from that, a great deal of "load time" (?) will likely consist of > the > time needed to parse the source code. Anything else is mostly > implementation- specific and thus varies from engine to engine. > > Could you state your question more precisely, please? > > On Thursday, June 22, 2017 1:59:05 AM CEST kai zhu wrote: > > and should future proposals take load-time performance into account? > > hi, i’m a new subscriber, and apologies if this seems like a newbie > question. > > a bit of trivia - i remember long ago (maybe 2010?) a website called > “great > computer language shootout” or something had d8 consistently having the > fastest load-time of all interpreted languages benchmarked. i recent > google-search led me to maybe the same website > (http://benchmarksgame.alioth.debian.org), but i can no longer find > load-time stats. > > -kai > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
