Hi Toon, The pattern of using Symbols to achieve private variables, or at least to avoid property naming collisions with derived classes, seems to be gaining traction.
http://raganwald.com/2015/06/04/classes-are-expressions.html Is there any indication of when this case will be optimised? Is it rising on the priority list? Thanks, Rob. On Thursday, September 18, 2014 at 4:48:07 AM UTC-4, Toon Verwaest wrote: > > 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] > <javascript:>> 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] <javascript:> >> 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] <javascript:>. >> 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.
