[Laszlo-dev] performance measurement of view creation speed doesn't seem to depend on dynamic vs sealed declaration after all

[P T Withington]

I could believe the JIT is not run on the Application class  
constructor, since it will only be executed once.  Most JIT's try to  
avoid compiling things that will only be executed once, since usually  
compilation+execution takes longer than just interpretation.  I would  
be surprised if the JIT is not run on _all_ class constructors.

(Actually looked at the referenced paper)

In the paper he says that 'class initializations' are interpreted, not  
constructors.  Initialization is code at the top level of the class,  
which would only get executed once, when the class is defined.

On 2008-02-14, at 17:34 EST, Henry Minsky wrote:

> Hmm, this article has an interesting note about not putting code into
> application constructors, because he says that
> the JIT is not run on class constructors for some reason
>
> http://blog.pixelbreaker.com/flash/as30-jit-vs-interpreted/
>
> He cites a performance tuning article from Adobe
> http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf
>
>
> I've been developing an application recently that requires large  
> numbers of
>> classes to be initialised as soon as the application is loaded.  
>> It's an
>> isometric display engine, a la "Sim City", with a world map of 800  
>> x 600
>> tiles, and multiple layers ( terrain, objects, transport networks  
>> etc)
>> there's potential for over 100,000 instances!!!
>>
>> I found ActionScript 3.0 and AVM2: Performance Tuning<http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf 
>> >by Gary Grossman, which covers many aspects of how AVM2 is  
>> different from
>> AVM1. The part I was interested in was about $init and $cinit (class
>> constructor) functions being interpreted and everything else being  
>> JIT.
>>
>> The initial setup of the engine runs over a timed loop (to stop  
>> script
>> timeouts), and this was typically taking 20 to 30 seconds. After  
>> reading the
>> above PDF, it became clear that class constructors are interpreted,  
>> not JIT
>> compiled, so all I had to do was move the code out of the  
>> constructor, into
>> an init() function, and call if after the constructor, this shaved  
>> a huge
>> amount of time off the initial build of the landscape.
>>
>> Some initial tests, with a for loop running from 0 to 10000 showed  
>> that in
>> the constructor it took about 350ms, and called via another method,  
>> it took
>> only 240ms. It is not always faster, but 90% of the time it's faster.
>>
>
> On Thu, Feb 14, 2008 at 5:11 PM, David Temkin <temkin at laszlosystems.com 
> >
> wrote:
>
>> It seems odd that if (1) classes are not declared as sealed, and (2)
>> no typing information has been added to LFC code, that we'd be seeing
>> the dramatic performance improvement over SWF8 that Henry has  
>> measured.
>>
>> Explanation?
>>
>> - D.
>>
>>
>> On Feb 14, 2008, at 10:52 AM, P T Withington wrote:
>>
>>> I take this to mean either:
>>>
>>> a) Their compiler is not taking advantage of sealing, yet.
>>>
>>> b) Their compiler is very smart and realizes that although your
>>> classes are declared dynamic, the are not extended in this
>>> application so they can be treated as sealed.
>>>
>>> On 2008-02-13, at 22:05 EST, Henry Minsky wrote:
>>>
>>>> I did some more testing of the view creation app (instantiating
>>>> 10,000 empty
>>>> views), and tried declaring
>>>> all of the base LFC classes (LzNode, LzView, LzEvent, lzDelegate)  
>>>> as
>>>> dynamic, and it did not actually
>>>> seem to make any significant  slowdown in the speed. The creation
>>>> speed
>>>> averages about 100 usecs  for
>>>> an empty view in either case.
>>>>
>>>> So whatever was causing the factor of two  slowness in the  tests
>>>> a couple
>>>> weeks ago was  some other bug.
>>>>
>>>> The 100 usec speed is with the flex debug flag off, with debugging
>>>> on it was
>>>> about 120 usecs.
>>>>
>>>> For comparison, the creation speed in swf8 seems to be about 330
>>>> usecs for
>>>> the same empty view.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky at laszlosystems.com
>>>
>>
>>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com