On 2013/08/13 14:10:21, Michael Starzinger wrote:
https://codereview.chromium.org/22545007/diff/20001/src/array.js
File src/array.js (right):
https://codereview.chromium.org/22545007/diff/20001/src/array.js#newcode1263
src/array.js:1263: if (!isProxy && %HasFastPackedElements(array) || i in
array)
{
It is _really_ surprising that the runtime call into
Runtime_HasFastPackedElements is cheaper than the "in" keyword. This
suggests
that there is a lot of potential in actually improving "in" in general.
This
needs investigation of the generated code!
A few things I noticed as I was investigating this.
- `in` calls into runtime code
- `in` does have a fast path for packed arrays
- but %HasFastPackedElements is faster because we can skip `in` entirely
since
we know that all indexes are in the array.
https://codereview.chromium.org/22545007/diff/20001/src/array.js#newcode1315
src/array.js:1315: if (!IS_UNDEFINED(element) || i in array) {
This is actually wrong as the i-th element might have a getter that
removes
the
element upon first access but still returns undefined. This will cause us
to
do
the "in" check on the property after the element has been removed.
We had this "optimization" for a while and it was removed. The test262
suite
should actually cover this case.
You are correct. I see it now.
I believe we still have this bug in reduce and reduceRight find_initial
loop.
https://codereview.chromium.org/22545007/
--
--
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/groups/opt_out.
