Skip navigation
Andrei Kouzmenkov
Currently Being Moderated

Very slow instantiation of components in SDK 4

Feb 2, 2011 4:18 PM

I'm working on converting an existing Flex application from SDK 3.5 to 4.1.

The app consists of a number of MX-only custom components, with some skinning.

The conversion itself wasn't a big issue, and after conversion the application works pretty much as good as before.



The only big problem is instantiation of visual components.

Under SDK 4 that takes 3 times longer!!!

Now switching to a new workspace takes 15 seconds instead of 3-4 before, which is unbearable!



For comparing the same code gets compiled with SDK 3.5 and SDK 4.1 and executed in the same environment.

With SDK 4.1 the app was attempted to be compiled in MX-only and MX+Spark mode, with Framework merged or RSL. None makes a difference.

Server-side code is the same.


I understand that old components may get somewhat slower under the new SDK, but 4 times!!!?

If this is the case, upgrading to SDK 4 makes no sense without rewriting all for Spark.

Even then where is the guarantee that the same problem doesn't exists for Spark components?



In Profiler comparable methods have similar timings, total numbers are also close.



Where is that black hole could be? Please HELP!!!

Did anyone observe similar behavior?



=== Flash Player debug; Flash Builder 4 Premium plug-in; Eclipse 3.5.2/3.6.0; Flex SDK 4.1; WinXP Sp3 32-bit / Windows 7 Ultimate 64-bit


Message was edited by: kolinitcom

  • Currently Being Moderated
    Feb 3, 2011 8:14 AM   in reply to Andrei Kouzmenkov

    I will be investigating another 3.x vs 4.x performance issue starting today.

    It may shed some light on your issue, otherwise I will try to look at your

    test case when I'm done with the other one.


    Call counts and cumulative times for calls in common may match, but there

    are different code paths in 4.x.  AddElement does other work before calling

    addChild, for example, and then each Group is trying to consolidate its

    display objects.  Your test case of one or two children per group is

    definitely non-optimal and somewhat pathological.

    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 1:32 PM   in reply to Andrei Kouzmenkov

    In both MX and Spark, fewer containers will be better, but the overhead

    might be more noticeable in Spark.


    Spark has replaceable layouts so you can write your own layout to manage

    more children and cut down on containers.


    Our main focus is on "reasonable numbers of containers and children".  The

    case I will be investigating is still showing a problem, although not a 3x


    Mark as:
  • Currently Being Moderated
    Feb 7, 2011 1:02 PM   in reply to Andrei Kouzmenkov

    Are you using the compiler in Flex 3 compatability mode?

    If so, according to the documentation, the compatability mode is using SDK 3.0 so could be some of the items you have built in your SDK 3.5 version could be causing the slow down if the compiler has to modify them using 3.0 assets.


    Just a thought...


    Mark as:
  • Currently Being Moderated
    Feb 7, 2011 1:17 PM   in reply to Andrei Kouzmenkov

    I started an analysis on your test case while watching the Super Bowl. I'm

    still rummaging through the data.  Definitely the MXML based skins are a

    huge factor.  So, I just compared the 3.5 version vs the 4.x version using

    the Halo theme.


    The main inefficiency seems to be related to the new style features

    (per-module styles and advanced CSS).  Advanced CSS is on for virtually all

    applications.  You can try stripping it out if you aren't going to use a

    defaultButton in your app.


    Along the way I found a couple of other inefficiencies we should probably

    correct.  The initialization of Checkbox is looks like it is doing duplicate

    work, so if you are creating lots of Checkboxes things will not look very



    You might find that things run a bit faster if you build the tree top-down

    like we do in MXML.  IOW, add the Vbox, then add the Hboxes to it, then add

    the CheckBoxes to the Hbox.


    Please file a bug with your test case and post the bug #.


    I haven't done any analysis of the Spark test case, and may not get to it

    right away.  It will be harder to analyze since there I can't really do a

    side-by-side like I could with the MX test case.  It will help to have a bug

    1. so I can have something official to spend more time on.


    Mark as:
  • Currently Being Moderated
    Feb 7, 2011 1:47 PM   in reply to Andrei Kouzmenkov

    Yeah. I'm very new to Flex 4  framework. More experienced with Flash. I have one combo box and 15 or 20 lines of code max, and I'm surprised at how long it takes to populate the combo box. It is reading a sqlite table, but still. Flash is much faster.

    Mark as:
  • Currently Being Moderated
    Feb 7, 2011 2:37 PM   in reply to Andrei Kouzmenkov

    MXML-based Themes like Spark are noticeably slower then AS-based themes like

    Halo.  We haven't done much research into why.  We'll probably answer that

    question after Hero ships.


    The default themes from Flex contain a .CSS file that uses Advanced CSS for

    the defaultButton (the button that has extra thick borders because it will

    be "clicked" when you hit ENTER).  There may be other advanced CSS selectors

    in the default theme.  Getting rid of them might speed things up a bit.


    If you have a lot of UI widgets, you should consider a UI that defers

    instantiation of as many widgets as possible based on navigators like

    Accordion or Viewstack or by States or by Modules.  It will make your app

    more scaleable in the long run, even if we speed up the framework itself.


    In theory, doing top-down instantiation should be possible by creating MXML

    components for the common patterns.  Lots of folks put all of their logic in

    an .AS file and just the UI widgets in the MXML file.

    Mark as:
  • Currently Being Moderated
    Feb 24, 2011 4:54 AM   in reply to Andrei Kouzmenkov

    Good post. On our project we have very similar problems.

    Thank you Adobe for looking into this. Just to let you know, more customers are waiting for a fix.

    Mark as:
  • Currently Being Moderated
    Feb 24, 2011 2:28 PM   in reply to Toni-Z

    Make sure you vote on the bug and add as a watcher to track progress.

    Mark as:
  • Currently Being Moderated
    Apr 22, 2011 5:56 PM   in reply to Flex harUI

    We saw massive inefficiencies in the way the styles were handled when we migrated to Flex 4 as well. As Alex mentiioned, when advanced CSS is on, it goes _slow_. In our case, we had about 300 styles in our stylesheet that Flex wanted to search through every time it instantiated an individual component. Flex would ask each style, "Do you apply to me?" and then ask the next one, "Do you apply to me?". When you do 300 of these queries per component instantiated, it bogs down quickly. So, for now I've monkey patched and we've gotten a ton of performance back.


    My fix was pretty hacky, and there are code paths that could cause my cache of styles to get out of sync, but it works for our purposes, and the idea of caching the simple style lookups in a dictionary could serve as the basis of a "real" fix by the Flex team.


    You can see my blog post and get the code here.

    Mark as:
  • Currently Being Moderated
    Apr 30, 2011 9:30 PM   in reply to Andrei Kouzmenkov

    What great news! Thanks for letting me know! I'm glad to hear it worked so well for you. I've yet to run our app through a profiler to figure out where else it is bogging down. After I make a few other migration fixes, I hope to. Our next release of our software is based on Flex 4 (to get font fallback and other features), but I am nervous about our next release taking a step backwards in performance. Hopefully I can find some other low hanging fruit.

    Mark as:
  • Currently Being Moderated
    Apr 30, 2011 11:54 PM   in reply to Andrei Kouzmenkov

    That particular performance issue is being tracked by this other bug:


    It is deferred for 4.5, but I expect it will get opened and looked at


    Mark as:
  • Currently Being Moderated
    May 1, 2011 4:44 AM   in reply to Flex harUI

    thx guys. this background and patch are awesome.

    Mark as:
  • Currently Being Moderated
    May 2, 2011 9:07 AM   in reply to Andrei Kouzmenkov

    We have also seen a tremendous performance lift after applying YNAB's css patch.  Our application if fairly large, with over 500 style declarations.  We display lots of information to our users in UI containers that are built dynamically based on data present for each display.  We continue to optimize our app to reduce nesting and simplify the UI presentation, but underlying SDK performance issues like this present a major hurdle in our migration to Flex 4.  To be honest, we can't launch the next release of our product without this issue being resolved.


    Adobe, please take a close look at the proposed fix and include your own solution as early as possible, hopefully in 4.5.1 or whatever the next release is.  It will be very much appreciated by your customers building enterprise apps.

    Mark as:
  • Currently Being Moderated
    May 2, 2011 9:53 AM   in reply to mcallinan-1

    focus on workarounds not adobe


    been doing that for 5 yrs

    Mark as:
  • Currently Being Moderated
    Oct 5, 2011 5:43 PM   in reply to Andrei Kouzmenkov

    Simple tests show that instantiation of visual components, adding them to the stage got 3-4 times slower than in

    SDK 3

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points