Hi Taras, Fx4 has already a good performance. If your app is well crafted, I think you should not notice nothing regarding that issue. I'm not saying that we should not bring new performance improvements, but what we have today is already very valid.
In big apps performance is important, but the benefits of Fx4 regarding skinning, FXG, advanced CSS and so on, are equal in importance. I'm assuming that the apps you talk are business apps for what Flex is well suited and not things like games or so... My opinion is that, if your business need a upgrade to Fx4, and your Fx3 is rightly done, you should try to migrate now and see if performance is really a problem. Maybe you think you can have a problem where probably you would not find anything. Best, Carlos 2012/8/27 Taras Kostyuk <tara...@gmail.com>: > As you know there are needed much time to move big apps from Flex 3 to Flex > 4 and there are a lot of risks. So, the main reason to do it is to get a > lot of benefits. Increasing performance can be a good benefit to do > migration, so it would be great to create appropriate tickets in flex > apache tracking system and start investigating it to increase performance > in next Flex releases. > > Thanks, > Taras > > 2012/8/24 Carlos Rovira <carlos.rov...@codeoscopic.com> > >> IMHO, performance is very important, but for the main use cases where flex >> is choose over other technologies (IT applications, form applications, >> large scale apps,...) the benefits introduced in Fx4 are critical. So we >> need to get better both of them (performance and ease of development). >> >> One of the things Alex comment in the blog post (order or addChilds in >> generated as3 code from mxml) seems to be something that could be done >> nowadays modifiync the mxmlc, isn't it? >> >> >> 2012/8/24 Tink <f...@tink.ws> >> >> > I started some stuff to see if I could remove the need for >> > SkinnableComponent to be a UIComponent. I didn't complete it but will get >> > back to it at some point. I would expect that to lighten initialization a >> > little. >> > >> > Tink >> > >> > Taras Kostyuk <tara...@gmail.com> wrote: >> > >> > >Links: >> > > >> http://jackviers.blogspot.com/2011/03/flex-3-vs-flex-4a-performance.html >> > > >> > >Unresolved issues on Adobe issue tracking system: >> > >http://bugs.adobe.com/jira/browse/SDK-29904 >> > >http://bugs.adobe.com/jira/browse/SDK-31719 >> > >https://bugs.adobe.com/jira/browse/SDK-29451 >> > > >> > > >> > >2012/8/24 Alex Harui <aha...@adobe.com> >> > > >> > >> >> > >> >> > >> >> > >> On 8/23/12 8:09 PM, "Jeffry Houser" <jef...@dot-com-it.com> wrote: >> > >> >> > >> > On 8/23/2012 5:30 PM, Taras Kostyuk wrote: >> > >> >> Hello Flex Community, >> > >> >> >> > >> >> Recently, I've read many articles that application developed using >> > Flex >> > >> 3 >> > >> >> SDK works much slowly on Flex 4 SDK. Also Spark component has lower >> > >> >> performance than MX. >> > >> > What have you read and do you have links? >> > >> Maybe here [1] >> > >> >> I am wondering if community has any plans to increase performance >> of >> > >> Spark >> > >> >> components and if so, when are you going to do it? >> > >> > >> > >> > Folks have expressed interest in working on performance. There >> are >> > >> > most likely some things that we can do; and in some cases the >> runtimes >> > >> > will limit us. >> > >> > >> > >> I'm always looking for ways to make things faster. Not sure there are >> > any >> > >> easy pickings out there. >> > >> >> > >> [1] >> > >> >> > >> >> > >> https://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-m >> > >> igrating-from-flex-3-x-to-flex-4-x.html >> > >> >> > >> -- >> > >> Alex Harui >> > >> Flex SDK Team >> > >> Adobe Systems, Inc. >> > >> http://blogs.adobe.com/aharui >> > >> >> > >> >> > >> >> >> >> -- >> Carlos Rovira >> Director de Tecnología >> M: +34 607 22 60 05 >> F: +34 912 35 57 77 >> <http://www.codeoscopic.com> >> CODEOSCOPIC S.A. <http://www.codeoscopic.com> >> Avd. del General Perón, 32 >> Planta 10, Puertas P-Q >> 28020 Madrid >> -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 35 57 77 CODEOSCOPIC S.A. Avd. del General Perón, 32 Planta 10, Puertas P-Q 28020 Madrid
