Comment #22 on issue 3087 by [email protected]: ES6: Array.prototype.slice
and friends should use ToLength instead of ToUint32
https://code.google.com/p/v8/issues/detail?id=3087
@ #21: Here goes a microbenchmark (not that I believe they are very useful,
though).
TL;DR: Impact still negligible in my opinion.
I have run the loop following loop (like before, 5 runs discarding
lowest/highest results), without passing the new “--harmony-tolength” flag,
so this is measuring the code path that checks the “harmony_tolength” flag,
and goes through “TO_UINT32” inside “ToLengthFlagged()”:
var data = [ /* Elements */];
for (var n = 0; n < 50000000; n++) {
data.slice(0, 0);
}
The results follow, for varying number of elements in the array — Note that
probably the results marked {§} cannot be taken as relevant, as they do not
seem to follow the trend:
* Before the patch:
- Empty array: 6.13s, 6.29s, 6.34s (average: 6.25s, 125ns/call)
- 10 Elements: 9.06s, 9.13s, 9.72s (average: 9.30s, 186ns/call)
- 100 Elements: 7.24s, 7.93s, 8.27s (average: 7.81s, 156ns/call) {§}
- 500 Elements: 9.92s, 10.31s, 10.05s (average: 10.09s, 201ns/call)
* After the patch:
- Empty array: 6.16s, 6.50s, 6.77s (average: 6.47s, 129ns/call)
- 10 Elements: 9.58s, 9.99s, 10.04s (average: 9.87s, 197ns/call)
- 100 Elements: 9.50s, 8.83s, 10.23s (average: 9.52s, 190ns/call)
- 500 Elements: 9.78s. 10.63s, 10.04s (average: 10.15s, 201ns/call)
In both cases. results for 1000 and 2000 array elements are very similar to
the result for 500 elements, yielding values around 200ns/call.
The overhead is a few nanoseconds, which is in the order of magnitude of
time for a function call and returning a value, as expected. Checking the
“harmony_tolength” flag seems to be ridiculously fast (the code generator
does a good job in there).
Note how as soon as there array reaches a few hundred elements the
difference fades away, indicating that the parsing and creation of the
array literal contributes a significant amount of time to the final result.
This also means that *in practice* in the code of real applications the
tiny difference in execution speed is not gonna be noticeable. Calls to the
affected functions are going to be a tiny proportion of the whole code, for
any relevant codebase, which means most of the time is going to be spent
elsewhere.
Case study: the “src/” subdir of React (https://facebook.github.io/react/)
is 38000 LOC, of which only ~400 lines contain calls to the functions
affected by this patch (a mere 1.3%, which is likely to be an overstimation
because I've just grepped for the function calls).
By the way, I have not checked the penalty with “--harmony-tolength”, but
it should be just slightly slower because of the additional call to
“ToLength()”, which eventually would go away when removing the flag, making
the overhead in that case similar to the one I have measured here.
Cheers,
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
