On 2014/05/14 14:02:31, arv wrote:
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.
Sure, but what I meant is to still have the changes array, but store it
over the
previous data table (which is no longer needed, and always large enough).
And as
I tried to argue above, writing that should be possible to do within the
same
loop that copies the entries over (i.e., the code remains almost the same).
I think we can also reuse one of the element count fields for the forward
pointer to the new table (i.e., the table is valid if that contains a smi,
and
deprecated otherwise). The other count field could be recycled to hold the
number of change entries.
2. We still need a special signal for Clear.
That's easy as well, just use a sentinel value for the number of changes,
i.e.,
-1.
Shouldn't that work? Everything would be just as efficient as now, but
without
using extra space.
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.
