are there metrics on how es6 and future proposals affect javascript load-time for webpages?
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?
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.
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.
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 ofExperiments.
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 @ kaizhu256.github.io/node-electron-onload-test/result.html, kaizhu256.github.io/node-electron-onload-test/result.html.
you can reproduce the experiment with the following script:
/*
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'
});
});
}());
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
onloadevent 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 me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
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 (benchmarksgame.alioth.debian.org), but i can no longer find load-time stats.