Our optimizing compiler does indeed not properly supported keyed named accesses. Only keyed indexed accesses are handled properly and fast. That has as a side effect that we currently don't support fast symbol access. So you won't get the same speed-up for those accesses are you get for regular property access.
Keyed accesses with literal (internalized) strings rather than symbols are turned into regular property accesses, so those are fast. This is indeed unexpected and should obviously be fixed. It's currently not very high on our priority list though. Regards, Toon On Wed, Sep 17, 2014 at 10:53 PM, Arnavion Dash <[email protected]> wrote: > Hi, > > I have a question about some JS code that's unexpectedly slow and I hope > this is the right list to ask about it. > > I made a change to the TypeScript compiler (a language that compiles to > JavaScript and adds some ES6 features such as classes) to compile private > class properties to use ES6 Symbols. Essentially, the generated JS for a > standard Point class with two private members x and y looks like this: > > var Point = function () { > // One Symbol created for each private property of the class. > var __symbol__x = Symbol("x"); > var __symbol__y = Symbol("y"); > > > // Constructor function > function Point(x, y) { > this[__symbol__x] = x; > this[__symbol__y] = y; > } > > > > // Some getters illustrating how to access the private properties. > Object.defineProperties(Point.prototype, { > x: { get: function() { return this[__symbol__x]; }, enumerable: > true, configurable: true }, > y: { get: function() { return this[__symbol__x]; }, enumerable: > true, configurable: true } > }); > > > > return Point; > }; > > > var point = new Point(10, 20); > console.log(point.x); > > > Before my change, the TypeScript compiler would generate private > properties as simply properties on the this object. The inner constructor > function would look like this: > > function Point(x, y) { > this._x = x; > this._y = y; > } > > and the two getters would read this._x and this._y respectively. > > > I benchmarked the two approaches and discovered the Symbol approach is > many times slower (it varies a lot between the environments I ran it but > it's anywhere between 10-100 times slower) than the simple "property on > this" approach. While trying to simplify this, I ended up with this: > http://jsperf.com/privates-using-symbols-vs-current-codegen/5 > > ClazzCurrent is the current codegen of the TS compiler. > ClazzWithIndexer is a modified version that uses string literals to index > "this" instead of dot-notation. > ClazzWithIndirection puts the string literals in a single-assignment var > outside the constructor function. > ClazzWithSymbols changes the vars to be Symbols instead of strings. This > is similar to the final Symbol codegen I initially started with. > > The > > Perf-wise, the first two are identically fast. The last two are > identically slow. > > - The fact that ClazzWithIndirection is also slow leads me to assume that > the slowness is not due to the use of indexing "this" with Symbols, but > indexing "this" with anything that's not a string literal or constant. Is > my assumption correct? > > - Is there any way to make ClazzWithIndirection and ClazzWithSymbols > approach the same level of performance as ClazzCurrent? > > - Is there a bug in the bug tracker I can follow for this? I did search > https://code.google.com/p/v8/issues/ for terms like "indexer" but didn't > find anything. > > > Thanks, > Arnav Singh > > -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
