On 1/14/15 11:52 AM, Dimitri Glazkov wrote:
Would like to point out that we're not talking about a general case
here. The actual proto munging in custom elements spec is minimized to a
pretty small set.
Pretty small set of which? Possible mutations, elements, something else.
Given that most engines use lazily created wrappers
I don't think we should be designing around this. I believe that this
is a carryover from the way the engines were initially implemented in a
C++-first manner. As a a particular example, Servo doesn't even have a
concept of "wrappers"; it just has a single memory area that is both the
JS and Rust representation of the object involved.
the actual setting
of the prototype won't even need to happen unless the developer first
accessed the element, thus creating a wrapper.
What that really means is that the performance cliff is randomly
unpredictable, right? That may or may not be better than always being slow.
Also, the current design doesn't change the prototype chain arbitrarily:
This is the most important point. It's possible engines could optimize
such proto chain insertions better than they do now. Some feedback from
engine implementors on how feasible that is would be good to have.
the effect is limited to inserting a sub-chain into the existing chain.
Is it, though?
I don't see that this is always true, though I would be fine with the
cases in which it's not true falling off performance cliffs: those would
only happen when proto chains get munged after element registration.
If we ignore those cases, it's possible JS engines could optimize this
better than they do now. JS engine implementor feedback would be pretty
useful on this matter.
-Boris
