On 2014/05/14 14:23:31, rossberg wrote:
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).
That makes sense.
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.
That too.
> 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.
Thanks. That is indeed a more efficient solution. It is less clean but it is
surely worth it.
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.
