On 2014/05/14 12:13:46, rossberg wrote:
This looks good already. But I wonder if we can do even better and avoid
allocating the extra array for changes? It seems like it should be
possible to
just reuse the existing data table slots for that. In particular, you are
guaranteed that the changes index moves slower than the old_entry index,
so is
always less-or-equal to it. Hence you even should be able to read entries
and
write changes in the same iteration.
I see two potential problems with that approach:
1. Iterating through entire existing data table on transition is a lot more
work
than only iterating through the holes. The question is what we want to
optimize
for? I think that changes during iteration will be rare so this should not
happen often but add always creating the extra changes array on rehash will
happen often.
2. We still need a special signal for Clear.
Conclusion:
1. Remove the changes array
2. Add a single entry describing the changes. This be used for "clear" but
it
could also be used for "no holes".
WDYT?
https://codereview.chromium.org/289503002/
--
--
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.
