Alex, you say the prototype was not faster, I suppose this is the case when all features are enabled which is actually a good result (if it's not slower). But the idea is that applications almost never require all features.
Regarding backward-compatibility, if it will prevent innovation, what about working on a new version that is not backward-compatible in parallel to the standard version? Existent applications continue to use the standard version which will be maintained with bug fixes and perhaps also some new features and when the newer version is out, let's say Apache Flex X (for 10), new applications will use it and old applications can be ported (but not required). Haykel On 24 January 2012 19:32, Alex Harui <aha...@adobe.com> wrote: > > > > On 1/24/12 10:20 AM, "Haykel BEN JEMIA" <hayke...@gmail.com> wrote: > > > I'm curious to see your work Alex. Were you able to do some performance > and > > memory tests with your prototype? > > > > Haykel > Further back in this thread I stated that the prototype was not faster > because of 'interstitial' costs: the cost of adding an additional function > call to get to the subobject that actually does the work. > > I think you have to give up on something: backward-compatibility, keeping > certain high-bandwidth 'behaviors' baked in', memory footprint, in order to > get gains. > > Or do something more clever like figuring out how to do post-process > optimization of the SWF that can set up tail-call optimizations and reduce > the interstitial cost. > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
