Message from discussion shapes and insertion order
Received: by 10.68.202.168 with SMTP id kj8mr9637434pbc.1.1335043178911;
Sat, 21 Apr 2012 14:19:38 -0700 (PDT)
NNTP-Posting-Date: Sat, 21 Apr 2012 16:19:38 -0500
Date: Sat, 21 Apr 2012 17:19:38 -0400
From: Boris Zbarsky <bzbar...@mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
Subject: Re: shapes and insertion order
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/21/12 5:07 PM, David Herman wrote:
> Also, I could imagine this might tax enumeration, since it has to go through the OrderMap indirection. But if this made ordinary property accesses faster, maybe it'd be worth it? Again, I'm probably embarrassing myself showing off my ignorance. But that'd be nothing new. :-P
This would only make ordinary property access faster if we kept the
invariant that a Shape determines the names corresponding to the slots
of an object, right? And that would mean that property addition would
need to memmove the slots array around as needed, because instead of
just putting the new prop at the end we'd need to put it somewhere in
the middle, in general.
And _that_ would make adding N properties to an object take O(N^2) time,
unless I'm missing something.
That might be OK, since N is typically small, and we could "deoptimize"
to just adding at the end for large N...
Plus of course having to maintain the order map. The upshot would be
possibly faster property reads and somewhat slower property additions,
right? Might be interesting to measure.