- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Wed, 14 Jan 2015 12:39:24 -0500
- To: Dimitri Glazkov <dglazkov@google.com>
- CC: public-webapps <public-webapps@w3.org>
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
Received on Wednesday, 14 January 2015 17:39:53 UTC