Received: by 10.68.202.168 with SMTP id kj8mr9637434pbc.1.1335043178911;
        Sat, 21 Apr 2012 14:19:38 -0700 (PDT)
Path: r9ni83090pbh.0!nntp.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
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
MIME-Version: 1.0
Newsgroups: mozilla.dev.tech.js-engine
Subject: Re: shapes and insertion order
References: <mailman.22875.1335042482.31724.dev-tech-js-engine@lists.mozilla.org>
In-Reply-To: <mailman.22875.1335042482.31724.dev-tech-js-engine@lists.mozilla.org>
Message-ID: <H4-dnSro3fr3uQ7SnZ2dnUVZ_sidnZ2d@mozilla.org>
Lines: 21
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 71.184.125.56
X-AuthenticatedUsername: NoAuthUser
X-Trace: sv3-5gLWEo4/RMzFEqvCNAgqkmcjlAc21i/POlLd7fvfHNpdBDz13n04aP9Uyhj34vABKFcmtcYVEkM5im5!ekidEkKgKwf8iWaSSrwdGLF5ECG+bDTin7rfo6ZvqClhbgq8eB6vdzzcNYoXQ+jqJNl8g2q80rGF!JolSOLjTnvEX
X-Complaints-To: abuse@mozilla.org
X-DMCA-Complaints-To: ab...@mozilla.org
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
X-Postfilter: 1.3.40
X-Original-Bytes: 2442
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

-Boris