A while back I posted some performance results of the Flex 4 Spark architecture vs. the Flex 3 mx architecture. In that post, I stated that the Spark components created a smaller binary deliverable. I hypothesized that this smaller binary size was due to the reusability of the Spark components and a result of fewer class definitions needed to create the code.
Some readers have suggested that the smaller application size was actually due to the default use of Runtime Shared Libraries in Flex 4 and that if I changed the Flex 3 application to use RSLs that it would be smaller. Another possible issue raised was that I used the debug version of the player to get the total runtimes.
So I recompiled, using RSLs in the Flex 3 application, and tested again, this time using the runtime player (version 10.2.154.27). The Flex 4 application was still about 30% smaller, at 55,866 bytes. The Flex 3 application weighed in at 80,645 bytes. Flex 4 still performed an average of 137% slower, or 384.38 ms slower on average than Flex 3.
I also generated a link report using -link-report. The Flex 4 build link-report reported 135 total references. The Flex 3 build link-report reported 480 total references. I assume that this proves my hypothesis that the Flex 4 Spark architecture reuses more code. I could be incorrect though. I look forward to hearing from someone who has more insight into interpreting mxmlc generated link-reports than I do to confirm or correct my analysis.
Happy Coding.
I've noticed this exact same issue. When I upgraded my company's entire application to Flex 4 with Spark components, I was surprised at the slow performance overall. These 'lightweight' Spark components were supposed to really shine with respect to speed and overall performance, but so far, it is clear that this is not the case. Very disappointing, especially at a time when Flex and Flash are under attach from HTML 5 and the (as yet unrealized and unavailable) benefits it offers.
ReplyDelete