are there metrics on how es6 and future proposals affect javascript load-time for webpages?

kai zhu kaizhu256 at gmail.com
Thu Jan 18 02:51:31 UTC 2018


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 <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 <kdex at 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-request at mozilla.org wrote:
>>>> From: kdex <kdex at 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 at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.12.34 AM.png
Type: image/png
Size: 260422 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.13.04 AM.png
Type: image/png
Size: 184737 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.13.18 AM.png
Type: image/png
Size: 190909 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.13.28 AM.png
Type: image/png
Size: 184363 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.13.38 AM.png
Type: image/png
Size: 187772 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.13.49 AM.png
Type: image/png
Size: 194859 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.14.01 AM.png
Type: image/png
Size: 197496 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.14.13 AM.png
Type: image/png
Size: 193951 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0019.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.14.20 AM.png
Type: image/png
Size: 182136 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0020.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.14.31 AM.png
Type: image/png
Size: 191475 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0021.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.14.41 AM.png
Type: image/png
Size: 195510 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0022.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-18 at 9.40.00 AM.png
Type: image/png
Size: 748801 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/da3199c4/attachment-0023.png>


More information about the es-discuss mailing list