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

[Henry Minsky]

The Adobe presentation said not to put performance-intensive code in class
initializers (code that executes once when the class is defined), but it
wasn't clear
whether they also meant constructors....


On Thu, Feb 14, 2008 at 5:34 PM, Henry Minsky <henry.minsky at gmail.com>
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
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080214/6d6742cb/attachment-0001.html