Re: 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

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

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

Re: Deterministic Proposal

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

Microtask scheduling

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.

Re: Deterministic Proposal

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

Re: Deterministic Proposal

> > 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

Re: Deterministic Proposal

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: > >

Re: Deterministic Proposal

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

Re: Deterministic Proposal

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

Re: Add timezone data to Date

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

Re: Deterministic Proposal

> 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

Re: Deterministic Proposal

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