T.J. Crowder tj.crowder at
Fri Jun 30 07:31:35 UTC 2017

On Fri, Jun 30, 2017 at 7:53 AM, Boris Zbarsky <bzbarsky at> 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:
>> 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 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list