It is an entirely different and brand new virtual machine, with it's own JIT, plus we are using their built in class system, so I would expect that they have substantially improved the execution engine under any circumstances...
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]
