On Fri, Jun 30, 2017 at 7:53 AM, Boris Zbarsky <[email protected]> wrote:
> On 6/29/17 1:49 AM, T.J. Crowder wrote: > >> I was going to make that very point, backed by a jsPerf, but the jsPerf >> doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array >> It says the minmax is faster on a 10-entry array (it reports the >> separate calls as 46-48% slower on V8 and SpiderMonkey). >> > > See https://jsperf.com/two-calls-vs-one-no-destructuring/1 which is the > same as the above-linked testcase but doesn't do destructuring of an array > into an arglist and the collapsing of an arglist into an array for every > call. In that one the two-call version is in fact faster. > > That is, the cost of allocating and filling the two-element return value > array is much smaller than the cost of allocating and filling the > 20-element array. Since the two-call testcase in > https://jsperf.com/two-calls-vs-one-returning-array does the latter > twice, it ends up slower than the version that only does it once. I was just sticking to how `Math.min` and `Math.max` work (e.g., they use discrete arguments). A better test probably would have passed them those args discretely rather than as ...nums. Interestingly, V8 still does the minmax faster than the separate calls to min and max in your test, rating the two calls version 21% slower than the minmax. As you noted, SpiderMonkey runs the minmax much slower than the two calls (61%). This is all a bit by-the-bye, performance is unlikely to be a big deal for minmax in the typical case, and when it is in a specific situation, a tailored solution to that specific situation would probably be best. The number of numbers being tested would have to be very large for two native-code loops to be the bottleneck in the code. I'd just drop the performance motivation from the proposal. -- T.J. Crowder
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
