flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject [FALCONJX] Get/Set code (was: superGetter very very slow)
Date Tue, 03 May 2016 20:58:13 GMT
I found time to look into this.  The current code for a getter/setter uses
anonymous functions and Object.defineProperties.  So:

private var _foo:int;
public function get foo():int
    return _foo;
public function set foo(value:int):void
   _foo = value;

Outputs js like this:

  foo: { 
         get: function() { return this._foo; };
         set: function(value) { this._foo = value; }

When we first started FlexJS, the JS output did not use
Object.defineProperties.  Instead the output was:

SomeClass.prototype.get_foo = function() {
    return this._foo;
SomeClass.prototype.set_foo = function(value) {
    this._foo = value;

This old output had some drawbacks:
1) lots of public methods that can't be renamed by the optimizer and thus
bloat the output
2) hard to read output in some cases.  For example, foo += 10 used to look

    set_foo(get_foo() + 10);

Where as it currently looks like:

    foo += 10;

But the new code has drawbacks as well:
1) When overriding a getter/setter, the output code looks up the
ancestor's getter/setter at runtime which is slow.
2) The call stack when debugging JS is harder to read as you can't tell
which getter/setter is on the call stack as easily.

That said, while the lookup code is slower than when we used the older
output, in my testing the JS still ran as fast as the debug SWF version.

Anyway, one option is to use a blend:
A) output get_foo, set_foo
B) use get_foo, set_foo in the Object.defineProperties.
C) Use the ancestor's get_foo, set_foo if a subclass only overrides the
getter or the setter but not both
D) Use get_foo, set_foo for super.foo calls.

D) is a bit controversial as it won't handle custom JS code that doesn't
conform to the get_foo, set_foo pattern.

Thoughts?  It will be a fair amount of work to implement these changes and
I don't think I would make it a high priority for me since we have code
that "works".


View raw message