Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.27 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>,
        "jeffry@dot-com-it.com" <jeffry@dot-com-it.com>
Date: Wed, 4 Jan 2012 14:28:50 -0800
Subject: Re: Flex performance
Thread-Topic: Flex performance
Thread-Index: AQHMyyc8hFSkOboeVkiC9FQLt7RGM5X9ExYAgAAB2wCAABPfAP//oVhu
Message-ID: <CB2A12A2.39109%aharui@adobe.com>
In-Reply-To: <CB2A8B6B.FA3A%frederic@exuvis.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

The large CSS file issue should be resolved in 4.6.  And Ryan will likely
submit another patch that makes it even better during state transitions.

It is important to profile your application to understanding why you are
having performance problems.   Sure, UIComponent can be refactored and
become more lightweight, but are you sure that's going to speed up our app?
Is the styles subsystem just slow or do you have too many display objects
off screen in your app?

That said, I hope to find time to start a discussion soon about my vision
for what should happen for Flex in Apache.

On 1/4/12 2:07 PM, "Fr=E9deric Cox" <frederic@exuvis.com> wrote:

> There will be numerous smaller things to tackle of course, I just wanted
> this general topic started to get some feedback.
>=20
> - I want UIComponent to be more lightweight
> - I want to reduce the performance cost of using styles and style
> selectors/descendants
> - I don't want UI to get blocked because of actionscript execution but us=
e
> workers or threading baked inside of the framework
>=20
> Those are more specific cases like you mention where we can focus on
>=20
> I avoid binding as much as I can because of the performance overhead, but
> in a lot of samples it was used because it is 'fast to develop with' to
> get people excited about Flex though it should be avoided if possible in
> larger projects
>=20
> On 04/01/12 22:56, "Jeffry Houser" <jeffry@dot-com-it.com> wrote:
>=20
>>=20
>>  I agree with the sentiment, but I don't think that "performance" is an
>> actionable item.  The Flex Framework is a big beast; what exactly do you
>> want to improve performance of?
>>=20
>>  If you were to say that "I want views in a mobile web app to change
>> quicker when using a viewChange effect" that would be something specific
>> someone could look into.
>>=20
>>  Or you could say "I want improved performance when using binding
>> inside an in-line itemRenderer"
>>=20
>>  I have solved a lot of "memory/performance" issues for Flextras
>> clients over the years strictly by re-writing their itemRenderers to not
>> use bindings, but to instead respond to the dataChange event.
>>=20
>> On 1/4/2012 4:49 PM, Arthur Lockman wrote:
>>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>>> noticed that on newer devices, it works fine. But on the slightly older
>>> ones, performance is a huge issue. Hopefully we can get in there and
>>> clean it up so it performs better.
>>>=20
>>>=20
>>> --
>>> Arthur Lockman | Senior Developer @ Vivace
>>> vi.vace.me
>>> Twitter: @arthurlockman
>>> a.rthr.me
>>>=20
>>>=20
>>> On Wednesday, January 4, 2012 at 4:28 PM, Fr=E9deric Cox wrote:
>>>=20
>>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>> of developers picking it up since it is easy to create rich
>>>> applications. However performance is often an issue.
>>>>=20
>>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>> skinned components (It is even worse with Flex 4 then it was with Flex
>>>> 3). When a Flex application gets really large the UI is blocked becaus=
e
>>>> there is too much actionscript code needed to get things running. (wit=
h
>>>> this I mean the processing time is acceptable but UI is blocked so the
>>>> perception is that things are slow)
>>>>=20
>>>> Therefore I'd like to vote on improving the performance of the Flex
>>>> framework where possible so new and existing applications can benefit.
>>>> Flex 4 with spark is great but comes with some performance drawbacks, =
I
>>>> hope we can improve on this significantly.
>>>>=20
>>>> I'm speaking on behalf of the experience and perception in the company
>>>> I work for, I'm curious to see if this is also a problem for the rest
>>>> of you.
>>>>=20
>>>> I'm not the expert here but I'd like to get involved and learn so I
>>>> can eventually help to fix issues but I believe UIComponent had some
>>>> overhead and this together with the StyleManager can cause performance
>>>> drawbacks in large applications
>>>=20
>>=20
>>=20
>> --=20
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=3D104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>=20
>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui