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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 > > >> [EMAIL PROTECTED] > > > > > > > > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
