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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kdex
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
In reply to this post by kai zhu
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, [hidden email] wrote:

From: kdex <[hidden email]>
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


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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kdex
> > 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, [hidden email] wrote:
> > From: kdex <[hidden email]>
> > 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: [hidden email]
> >
> >
> > 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

kdex
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, [hidden email] wrote:
> > > From: kdex <[hidden email]>
> > > 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: [hidden email]
> > >
> > >
> > > 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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.

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"
    for uu in \
        https://www.baidu.com \
        https://www.yahoo.com \
        http://www.qq.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 <[hidden email]> 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, [hidden email] wrote:
From: kdex <[hidden email]>
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: [hidden email]


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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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, [hidden email] wrote:
>
> From: kdex <[hidden email]>
> 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: [hidden email]
>
>
> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss