[Bug 27346] Data properties


--- Comment #4 from Boris Zbarsky <bzbarsky@mit.edu> ---
I can best speak to the Gecko+SpiderMonkey and Servo+SpiderMonkey
implementation; it might be worth checking with other implementors in terms of
what things look like for them.

In the Gecko+SpiderMonkey implementation, allocation of a platform (Web IDL)
object is a two-stage process.  First the appropriate C++ object is allocated. 
Then a JS reflection for it is created.  The per-instance state that's not
lazily computed is stored in the C++ object, so doesn't involve any work on the
part of SpiderMonkey at all.

In Servo+SpiderMonkey there is a single object, but it has a known list of
internal slots and tells SpiderMonkey how many internal slots it wants
allocated.  These internal slots do not involve any work to allocate past
allocating a bigger chunk of memory and default-initializing them with the
undefined value.

On the other hand, defining a value property on an object involves a bunch of
work on the part of SpiderMonkey: updating the hidden shape, updating type
inference information, ensuring that there is a slot for the property, etc,

Some of these things can be optimized away a bit if the exact set of properties
is known up front by preallocating the slots at least; SpiderMonkey doesn't
expose public APIs for this, but that can be fixed.  But the type inference
information and shape information would still need to evolve.  Basically, the
JIT can optimize access to value props a lot more than built-in getters, but
that comes at the cost of needing to do more bookkeeping when setting up the
props.  In practice, that's worth it in the benchmarks... because those touch
the props they set up.  But I'm worried about people setting up a whole bunch
of "just in case" props.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 17 November 2014 15:44:28 UTC