On 2/25/12 10:42 AM, "Michael A. Labriola" <labri...@digitalprimates.net>
wrote:
>> 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);
addChild(foo);
}
function method2()
{
var foo:Label = new Label();
foo.someOtherProperty = someOtherValue;
foo.setStyle("someOtherStyleProperty", someOtherStyleValue);
addChild(foo);
}
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.
http://blogs.adobe.com/aharui
