Private symbols as WeakMap sugar

Andreas Rossberg rossberg at
Fri Jan 18 02:04:58 PST 2013

On 17 January 2013 21:08, Brendan Eich <brendan at> wrote:
> Andreas Rossberg wrote:
>> 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.
> Probably I'm more sensitive to the "generic" case, which while dog slow
> still dogs some real-world critical paths (if not fake/lame/old benchmarks).
> It all costs, David is proposing yet another cost. Maybe that's my final
> answer :-|.

I don't know enough about the internals of other VMs, but at least in
V8, the generic case will jump into the C++ runtime (costly) and
potentially trickle through hundreds of lines of logic. I think you
will have a very hard time constructing even a highly artificial
benchmark with which one additional conditional in that logic would be

Obviously, that doesn't imply that I consider it a good idea... ;)

>> 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.
> In contrast, private symbols (any symbols, public/unique or private) should
> benefit from existing property-in-receiver optimizations. Right?

Perhaps, perhaps not. For V8, we haven't really thought hard yet about
how they fit into the existing representation. They may still end up
requiring a case distinction somewhere.


More information about the es-discuss mailing list