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