No, this is not April Fools, this is straight up scary, Halloween scary, Flex issues. I urge people to test and look at this post to make sure we are not missing something. Many of us here at 9m have looked at this issue and we have all determined that Flex 3 has major memory and performance issues that did not exist in Flex 2.
I will only briefly explain since the posted example results and code say it all.
When opening and closing a container that has a bunch of UIComponents, memory is seen to climb as well as response time. The test harness is a simple setup that only creates containers full of ComboBoxes (we even used just labels in other tests), then removes them. All memory cleanup best practices are used. In fact this is such a simple test of the framework there really isn't much that could go wrong.
Are we missing something? This is kind of ridiculous. How can we be the only ones to have found this? I'm not explaining most of our story, but bottom line, our client had some serious show stopper issues that could have cost them many many thousands of dollars and destroyed their business had we not rolled back to Flex 2! Unbelievable!
Checkout the code here:
http://code.9mmedia.com/svn/public/flex-performance-test/trunk
For the lazy, live swfs here:
http://9mmedia.com/examples/performance/flex2
http://9mmedia.com/examples/performance/flex3
**note** don't hit start test more than once 
You will have to point to the right SDK paths on your machine, but I will let you figure that out.
Below are results of running the version in bin-release (as to rule out any debug code) with each SDK. Memory is in orange and response time to open the tab and load the components is the blue line.
Flex 3.1:
The only strange thing here is that at around 160 performance came back a bit. We don't always see this....more spooky things lurking around I guess....
Flex 2.0.1
I don't think it's coincidence that these look like cardiographs, as I have had at least 4 heart attacks trying to get to the bottom of this.
We are hoping we missed something simple here. Please run the tests, look at the code and post any at all findings!!!!
13 Comments
The link for the source is returning “Secure connection failed” error. Depends of the container type, type of positioning (relative positioning takes more time, i.e. percent widths/heights) and usage of constraint layouts (i.e. top/bottom/left/right) in such cases like the example above is a suicide. Lastly, play around with creationPolicy options (if didn’t already).
But things might be clearer if I see the actual sources.
Dimitar G.
I agree with Dimitar about the the repository access. Would be nice to see the code.
I ran the swfs in FP 10 and found it appeared that Flex 2 was faster than 3 though by how much I can’t really say (maybe 0.1 of second). Though would have been nice with your swfs to show the total average and not a visual guess.
One thing you don’t note is that Flex 2 uses a lot more memory than 3 in your graphs. So that would imply Flex 2 is more memory hungry?
When I did run the swfs you provided I could not replicate the general shape shown in your graphs. Both of my graphs were a lot smoother than yours with both memory and processor time not increasing over time.
So at this stage I wouldn’t jump to any conclusions that Flex 2 out performs 3 at some scary level. I’d be cautious to conclude anything till something more substantial starts to reoccur and can be replicated.
Ross
check for memory leaks, period.
I could help more with access to the source too, but basically
just declaring style in mxml could cause memory leaks
and you’re not the only one, check for memory leaks in the Flex JIRA,
you will see different entries that may help
ex: if you us the charting component, upgrade directly to the 3.2 Flex SDK (which solve memory leaks).
The bottom line is if you need performance, you code Flex right from the start with performance test, if you check at the end of the project to do that erm.. you end in hell
.
see it like that, C was not automagically cleaning the GC,
and Flex does not automagically clean memory leaks.
I have updated the code link. I just changed https to http.
- You will see better performance with FP10 so test should be run with 9. Degradation takes longer is all.
- If you see a flat line in the flex 3 test, you will need to add some weight to the test. On faster computers this is a must. I can post a test that includes skins and you can see a degradation after 15 open/closes.
- There are no memory leaks, the code is so very simple. I have also checked with memory profiler and there are no objects I can see lurking around.
- Creation policy didn’t change the behavior either, I have done the test with solely vboxes being popped up.
sorry about the code link…you should have been able to access even though the certificate error occurs for our https.
All the things below are based on SDK 3.1.0.2710 (the official release).
You have couple of options to speed up compilation and code execution, especially when heavy-duty testing of UI objects
- Component development – Use AS than MXML creation. Avoid using percentWidth/percentHeight (in AS) or width=”value%” height=”value%” i MXML. Avoid using styles or constraint values for anything.
- Container usage – Panel and TitleWindow are heavy. Any relative positioning needs more time to measure and rearrange its children. So Canvas with exact x/y/width/height values is best for such things. Your Form.mxml could be transformed into 50 lines of AS3 component which extends mx.core.UIComponent. TestWindow.mxml should extend Canvas to ease some resources too.
- TabNavigator is heavy too. Might need to use Canvas to ease the pain of creation and refreshing windows.
- Compilation – Caching the framework into swz speeds code execution 15/20% (on my machine). So detach the framework into a swz.
As zwetan emphasized, performance optimizations should be in mind through the whole coding process or at the end things are getting messy.
I think people might be missing the point here. The important part of this post is not general performance optimization. It’s the fact that 1) performance degrades over time using simple code that doesn’t contain memory leaks, and 2) that the degradation is drastically worse when the same code is compiled in Flex 3 versus Flex 2. I have yet to hear a satisfactory explanation from Adobe or anyone else why performance would be significantly worse using Flex 3 than it had been previously. It was a major problem for this project and in this case has seriously undermined the client’s faith in the Flex platform.
Just out of curiosity (since we are battling Flash Player memory issues here too) did your tests with your code (no changes implied, as it is), exported as release build, tested on local CF8. The machine used is 2 GBs RAM, 2.4GZ dual core, Vista Ultimate SP1, IE7, FP 10 Debug.
I did 2 tests: with and without swz of 3.1 framework. Results are flat, no memory spikes and 2/3% faster execution when swz is applied.
Might be my machine but as I said, 2 tests in a row and both point to flat usage of memory.
Did screen shots of the results so if you need them, let me know.
weird, running the 2 live test the flex 3 version actually outperform the flex 2 version. both shows a flat memory usage as well.
firefox 3.04 / fp10
save to my Bookmarks
Interesting post, I’m running your tests now but I just noticed that your ‘lazy’ links are incorrect, they are both linking to Flex 2 ( http://9mmedia.com/examples/performance/flex2 )
Thanks, you are right! Doh. Links are fixed now.
I ran a bunch of tests with this and didn’t see the execution time budge much at all. I tried it with 500 iterations as well. Just curious, are you still seeing these issues with Flex 3.2?
a performance related article for flex
http://askmeflash.com/article/9/optimize-flex-swf-filesize-performance-loading