Slow Spark List Initialization with custom renderer

1
votes

I have a Spark list with a customItemRenderer that is taking a good 3 seconds to initialize with just 50 items.

I'm using Flex 4.5, my ItemRenderer is already very optimized, using as little nesting as possible, fxg and so on.

Is anyone having similar issues? I've tried almost everything in the book bar going back to mx.

4
apache-flexflex4.5itemrendererflex-spark
How many items are you showing at the same time? Please post your code as well. – Dennis Jaamann
I removed the bindings and although it did produce a small performance improvement it still takes about 4 seconds to display the list, it currently has 8-10 displayed items. – Pedro
@DennisJaamann: I can't fit the code here but it looks like simple logic on set data and then for the renderer: Group Group fxg for bg s:Label Group BorderContainer for selection state Group Rect BitmapImage HGroup VGroup (this part times 3) BorderContainer Label Hope this makes sense. Thanks! – Pedro

4 Answers

2
votes

So the issue was due to the way that spark handles styling the issue is detailed here: http://bugs.adobe.com/jira/browse/SDK-29880 and can be sorted by monkey patching with: http://taytay.com/?p=169 Also removing global css selectors "*" helps.

1
votes

Avoid HGroup and VGroup as much as possible, use absolute layout instead. I've had this same problem at that's fixed most of it for me. 1 hgroup + 1vgroup each three times = 6 automatic layouts PER ITEM. So in total you have 150 objects, WAY too much.

1
votes

After applying the monkey patch mentioned by Pedro with only modest performance gains (I suppose we had fewer styles, or the performance was fixed in a more recent patch), I continued profiling the initialization of our List instances.

One thing I found is that Flex spends quite a lot of time in UIComponent's initializeAccessibility function, even though our application does not support accessibility in any way (whether applications ought to do that is an entirely different issue).

Merely adding -accessible=false to the compiler arguments cut time spent initializing a particularly heavy list by about a third! Not only that, the whole application in general feels snappier when windows are opened, controls are shown for the first time, etc. If you have no need of accessibility support, you might want to check this out - if you do, I'm sure something can be done to fix the abysmal performance of initializeAccessibility - simply through overriding it in your component implementations, or through even more monkey patching :-)

0
votes

Are your item renderers checkboxes by any chance? A few folks have recently run into a bunch of performance issues with Spark in general.

http://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-migrating-from-flex-3-x-to-flex-4-x.html

Adobe has been notified, and apparently are working on it: https://bugs.adobe.com/jira/browse/SDK-29451