Right. And if you're project was 1MB and you could get 10 more frames per
second out of an optimization that added 50kb then you'd want to flip that
switch. What I mean is that it's the type of choice you could add as a
compiler option. We already have to make the size vs speed vs convenience
choic
>> It sounds like a decision that has to be made by the project. For
>> mobile
>> apps size is not as much of a concern as performance.
> Probably true, but I hear lots of complaints about folks hitting some
limit the Apple Store approvers don't like.
>
> Alex Harui
> Flex SDK Developer
> Adobe Sys
> -Original Message-
> From: jude [mailto:flexcapaci...@gmail.com]
> Sent: Friday, January 27, 2012 6:01 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Optimize Flex performance
>
> It sounds like a decision that has to be made by the project. For
> mobi
It sounds like a decision that has to be made by the project. For mobile
apps size is not as much of a concern as performance.
On Thu, Jan 26, 2012 at 2:48 PM, Gordon Smith wrote:
> The Falcon compiler will have some bytecode optimizations that the current
> compiler doesn't do, such as constant
Adobe
-Original Message-
From: Gordon Smith [mailto:gosm...@adobe.com]
Sent: Thursday, January 26, 2012 12:49 PM
To: flex-dev@incubator.apache.org
Subject: RE: Optimize Flex performance
The Falcon compiler will have some bytecode optimizations that the current
compiler doesn't do, such a
The Falcon compiler will have some bytecode optimizations that the current
compiler doesn't do, such as constant propogation. But in general, the question
of which optimizations belong in the compiler and which belong in the JIT is
tricky. If you put them all in the compiler, the SWF size could
