flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Compiler Array Implementation ( was Adobe / Apache / Spoon Flex Tour )
Date Sun, 26 Feb 2012 08:02:29 GMT

On 2/25/12 10:42 AM, "Michael A. Labriola" <labriola@digitalprimates.net>

>> The current implementation is that all tags are encoded into an array that
>> gets interpreted during a method call in the lifecycle of the container so it
>> can be intercepted or the array can be modified up front.  There are >plans
>> for an API for manipulating the array.  It turned out to be much faster to
>> read the array than a data structure.
>> But it is just a stake in the ground and can certainly be changed.
> Alex,
> Is it possible for you to discuss this more here without violating NDAs, etc.
> with Adobe. To be very clear, I am currently working on the research before
> implementing a series of compiler changes geared toward run-time performance
> gains for the framework. I also plan on implementing several features that I
> have wanted for a while. To that end, I will soon be addressing the way the
> code gen occurs from MXML as this is a pain point for me. I am hoping to get
> some of the thoughts you have already on this.
I will check with my legal advisors on whether I can just copy a
spec/proposal I had written up, but basically, the data I have is that the
method currently generated for a tag turns out to be much faster than I
would have guessed.  I expected the cost of verify-and-jit for each of the
methods which only get used once would be easy to recover.  It turned out
that the cost of working with a data structure is even more expensive even
though you should be gaining advantages of re-using the verify-and-jit.

For example, if you have N methods that look something like this:

 function method1()
    var foo:Button = new Button();
    foo.someProperty = someValue;
    foo.setStyle("someStyleProperty", someStyleValue);
 function method2()
    var foo:Label = new Label();
    foo.someOtherProperty = someOtherValue;
    foo.setStyle("someOtherStyleProperty", someOtherStyleValue);
You might want to run them through a data-driven loop:

    var childData:Array = [
        { clazz: Button,
            properties: [ "someProperty" ];
            propertyValues: [ someValue ];
            styles: [ "someStyleProperty" ];
            styleValues: [ someStyleValue ];
        { clazz: Label,
            properties: [ "someOtherProperty" ];
            propertyValues: [ someOtherValue ];
            styles: [ "someOtherStyleProperty" ];
            styleValues: [ someOtherStyleValue ];

    for (var index:int = 0; index < childData.length; index++)
        var childInfo:Object = childData[index];
        var foo:UIComponent = new childInfo.clazz();
        if (childInfo.properties)
            for (var j:int = 0; j < childInfo.properties.length; j++)
                foo[childInfo.properties[j]] = childInfo.propertyValues[j];
        if (childInfo.styles)
            for (var j:int = 0; j < childInfo.styles.length; j++)
                foo.setStyle(childInfo.styles[j], childInfo.styleValues[j]);

But I was unable to find something that was faster and still looked like a
data structure.  I did the usual optimizations of loops, local variables,
class definitions instead of just Object, etc.  I think one of the issues is
the cost of setting up the data structure.

What is as fast as the methods is a single array of encoded data with a loop
that decodes it.  So, you might pack everything in an array like this:

    [ Button, "someProperty", someValue, null, "someStyleProperty",
someStyleValue, null, Label, "someOtherProperty", someOtherValue, null,
"someOtherStyleProperty", someOtherStyleValue"];

You can play around with using null as a delimiter between properties and
styles or putting in the number of properties and styles or whatever, but I
think this is fast because the array setup time is much faster than data
structure setup time, and then you get to leverage the verify-and-jit.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message