On 16 January 2013 20:27, Brendan Eich <bren...@mozilla.com> wrote:
> David Bruant wrote:
>>
>> Le 16/01/2013 19:42, Brendan Eich a écrit :
>>>
>>> David Bruant wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is an idea naturally derived of all the current discussions about
>>>> WeakMaps and Private symbols. The proposal is easily summarized by these
>>>> lines of code:
>>>>
>>>> var wm = new WeakMap();
>>>> var o = {};
>>>> o[wm] = 12 // desugars to wm.set(o, 12)
>>>> var a = o[wm]; // desugars to wm.get(o);
>>>> wm in o // desugars to wm.has(o);
>>>> delete o[wm] // desugars to wm.delete(o);
>>>
>>>
>>> You are not showing the desugaring in general:
>>>
>>> function get(o,x) {
>>> return o[x];
>>> }
>>>
>>> must transform to
>>>
>>> function get(o,x) {
>>> return (x is WeakMap) ? x.get(o) : o[x];
>>> }
>>
>> You're right, I hadn't thought of that.
>>
>>> This is not an acceptable hit for every []-named property access.
>>
>> I intuit (and may be wrong) that even just observing types (weakmap or
>> stringified type) passed to a []-access can be a good indicator of how best
>> []-named property access should be JIT-compiled. You pay the price of the (x
>> is WeakMap) test only the time the JIT warms up.
>> Given what's in current engines, it sounds doable.
>
> No, it's a hit, pure and simple. Engines do various things, SpiderMonkey
> does semi-static analysis (type inference), but in generic code, you propose
> to add a ?: to every [] operation. I think that's a non-starter. I invite
> others (Andreas R. especially) to weigh in.
Actually, I don't see why this should have a measurable impact on
performance in practice. The "generic" case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
actually seen at runtime. And there, this would just add yet another
row to the (already complex) matrix of cases for receiver/index type
pairs that you optimize for. The same might actually be true for
symbols, depending on the implementation strategy.
Like any new type or representation, it may cause deoptimization and
increased polymorphism, but that's nothing new under the sun, and we
are adding plenty of that with ES6.
/Andreas
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
