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

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Guy Ellis]

My thoughts are along the lines that the developer would decide what a
deterministic function was and decorate/tag it as such. That's why I used
the word deterministic and not pure. Basically the developer is signaling
the compiler that given an identical parameter signature the result
received back from the first call can be used for all subsequent results.

The developer implementing compiler optimization would then have a flag
available against any method that would signal if it is deterministic or
not and would decide to use that information or not.

The question is: Would that extra information provide the Compiler
Optimizing Developer with information that they could use to improve
performance or anything else? If you are/were such a
Compiler-Optimizing-Developer how would you use this information?

On Wed, Jun 21, 2017 at 9:59 AM Andreas Rossberg 
wrote:

> On 21 June 2017 at 18:40, Bradley Meck  wrote:
>
>> You probably mean "pure", not "deterministic", which has nothing to do
>>> with this. However, JavaScript is far, far too impure for any such
>>> annotation to ever make sense or enable any sort of memoization. Consider
>>> let i = 0
>>> let o = {valueOf() {return i++}}
>>> sum(o, 0)
>>> sum(o, 0)
>>
>>
>> If type coercion was disabled within "pure" functions I am not sure this
>> would be a problem.
>>
>
> A new language mode with modified semantics is a whole new dimension that
> is far from simple to add to JS. And even then the pure subset of JS would
> remain tiny.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Microtask scheduling

[Isiah Meadows]

It's a relatively low-level operation, but in performance-sensitive
async code and polyfills, there's still a strong need for raw
microtask scheduling, at a much lower level than promises. In
particular, there's two very frequently used modules providing a
wrapper for this specific thing:

1. next-tick: A browser polyfill for Node's `process.nextTick`, with
over 2M downloads last month and 88 direct dependents.
2. asap: A microtask scheduler that avoids blocking Node's I/O loop,
with over 7M downloads last month and 88 direct dependents.

In addition, several libraries like Bluebird have to implement their
own wrappers to gain similar functionality without assuming another
dependency.

Any chance something like Node's `process.nextTick` could be added,
maybe something like `Promise.schedule(func, thisArg, ...args)`?

-

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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Andreas Rossberg]

On 21 June 2017 at 18:40, Bradley Meck  wrote:

> You probably mean "pure", not "deterministic", which has nothing to do
>> with this. However, JavaScript is far, far too impure for any such
>> annotation to ever make sense or enable any sort of memoization. Consider
>> let i = 0
>> let o = {valueOf() {return i++}}
>> sum(o, 0)
>> sum(o, 0)
>
>
> If type coercion was disabled within "pure" functions I am not sure this
> would be a problem.
>

A new language mode with modified semantics is a whole new dimension that
is far from simple to add to JS. And even then the pure subset of JS would
remain tiny.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Bradley Meck]

>
> You probably mean "pure", not "deterministic", which has nothing to do
> with this. However, JavaScript is far, far too impure for any such
> annotation to ever make sense or enable any sort of memoization. Consider
> let i = 0
> let o = {valueOf() {return i++}}
> sum(o, 0)
> sum(o, 0)


If type coercion was disabled within "pure" functions I am not sure this
would be a problem.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Andreas Rossberg]

On 21 June 2017 at 00:58, Guy Ellis  wrote:

> I have an idea rattling around that allowing the developer to mark a
> function as deterministic would allow the compiler to determine if a
> speed/memory memoization trade-off will improve performance.
>
> Possible syntax:
>
> deterministic function sum(a, b) { return a + b; }
>
> Use case:
>
> I can only think of one right now: compiler memoization
>

You probably mean "pure", not "deterministic", which has nothing to do with
this. However, JavaScript is far, far too impure for any such annotation to
ever make sense or enable any sort of memoization. Consider

let i = 0
let o = {valueOf() {return i++}}
sum(o, 0)
sum(o, 0)

 On 21 June 2017 at 17:34, Isiah Meadows  wrote:

> I'd like to note that even Haskell compilers (which can check for this
> trivially) never memoize implicitly. They only memoize infinite data
> structures.
>
> [...]
>
> The only time I have found memoization to be very useful is in one
> specific case: lazy evaluation (run once). But that is constrained to
> just evaluating a thunk and storing the result.
>

I think you are confused. Laziness and memoization are different
mechanisms. And neither takes the finiteness of a data structure into
account.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Michał Wadas]

To be honest it's probably solvable using decorators with memoization.

If we ever have a decorators (any updates on proposal BTW?) language can
have decorators with implementation-specific behaviour (eg. "functions
decorated with @pure builtin decorator can be assumed by engine to not
produce side effects and became a subject of lazy evaluation" or
"@memorySizeCache(size) builtin decorator has semantics almost identical to
builtin @cache decotor, but engine can drop entries in cache if it exceeds
given treshold "). Fallback for other implementations would be of course
no-op.



On Wed, Jun 21, 2017 at 5:34 PM, Isiah Meadows 
wrote:

> I'd like to note that even Haskell compilers (which can check for this
> trivially) never memoize implicitly. They only memoize infinite data
> structures.
>
> As for this proposal, I see exactly zero benefit whatsoever. Engines
> already cover the relevant optimization opportunity without this
> (through type ICs), and it's often faster in practice to recalculate
> than memoize based on argument.
>
> The only time I have found memoization to be very useful is in one
> specific case: lazy evaluation (run once). But that is constrained to
> just evaluating a thunk and storing the result.
> -
>
> 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, Jun 21, 2017 at 6:01 AM, Jussi Kalliokoski
>  wrote:
> >
> >> deterministic function sum(a, b) { return a + b; }
> >
> >
> > Ironically, having the engine decide when to memoize would make the
> > "deterministic" functions non-deterministic:
> >
> > deterministic function foo(a, b) { return { a, b }; }
> > foo(1, 2) === foo(1, 2) // may or may not be true
> >
> >
> > ___
> > 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

Re: Deterministic Proposal

[Isiah Meadows]

I'd like to note that even Haskell compilers (which can check for this
trivially) never memoize implicitly. They only memoize infinite data
structures.

As for this proposal, I see exactly zero benefit whatsoever. Engines
already cover the relevant optimization opportunity without this
(through type ICs), and it's often faster in practice to recalculate
than memoize based on argument.

The only time I have found memoization to be very useful is in one
specific case: lazy evaluation (run once). But that is constrained to
just evaluating a thunk and storing the result.
-

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, Jun 21, 2017 at 6:01 AM, Jussi Kalliokoski
 wrote:
>
>> deterministic function sum(a, b) { return a + b; }
>
>
> Ironically, having the engine decide when to memoize would make the
> "deterministic" functions non-deterministic:
>
> deterministic function foo(a, b) { return { a, b }; }
> foo(1, 2) === foo(1, 2) // may or may not be true
>
>
> ___
> 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

Re: Add timezone data to Date

[medikoo]

Timezone data is already *indirectly* accessible via native
Intl.DateTimeFormat (I've also once published an util that allows to work
that: https://github.com/medikoo/date-from-timezone ).

Still it would be way better if there's some direct access provided, whether
it should be directly on Date or on Intl.DateTimeFormat is to be discussed
(I would possibly vote for Intl.DateTimeFormat)



--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Add-timezone-data-to-Date-tp366272p366292.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Jussi Kalliokoski]

> deterministic function sum(a, b) { return a + b; }
>

Ironically, having the engine decide when to memoize would make the
"deterministic" functions non-deterministic:

deterministic function foo(a, b) { return { a, b }; }
foo(1, 2) === foo(1, 2) // may or may not be true
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[peter miller]

Hi,

Think of it like this: It might be enough for your application only to  
memoize
the last `n` results. If you don't, depending on your function, you  
might be

blowing up memory rather quickly.



But I don't know how much memory my data uses or how much memory is  
available. So I don't know how quickly I'm blowing up memory. We need help  
with the environment with caching.


Peter

--
"There were drawings, and sheets of paper with writing on them, and it  
seemed that they were the sustenance of life, that here were the warlocks,  
almost the vehicles of destruction of man's life, but at the same time the  
very reason for his living." --- Maeve Gilmore/Titus Awakes.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss