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 <[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]
