This may be common knowledge or may not but I figured I would sound off on the topic. During some performance optimization a coworker came across some issues with container type classes in Flex, specifically nested containers. We had some less-than-ideal approaches regarding the layout of some of our custom components within our application.
For instance, we have a class that was in the general sense, a modified image type class with some mouse event handlers. Rather than extending the image class using the OOP’s “is a” mentality, it was developed with the “has a(an)” approach. This meant that the class base was something like a container with an image instance contained within. Then the mouse event handlers were assigned via the MXML events on the image item. I’d attribute this development approach to the fact that the person was probably crunched for time, frequent refactoring due to the Agile approach we have adopted, and/or they were not familiar in programming event handlers for a class’s own events (i.e. tapping into the mouse events on a Image subclass and assigning internal handlers).
Now I am not saying there is a huge performance difference in the “has a” approach. On a one-to-one comparison you’d probably be hard pressed to see even a significant difference. But on larger applications where there are dozens, if not hundreds of container type classes being used, it could mean the difference between fast rendering and very sluggish rendering. In our case, my coworker refactored a small section of the application and saw improvements that resulted in seconds, not milliseconds.
The reason for the performance hit is this (or at least my take on it): Every time updating occurs on dimensions, positions, indexes, children, etc., there are a whole slew of methods that fire off. This is compounded if the container in question has children because normally they too call those methods for themselves. So now we are taking a slight performance hit and exponentially increasing it. Of course all these things are taking place very quickly but still, performance is taking a hit.
So the suggestions for improvement are:
- reevaluate the “is a” vs. “has a(an)” relationship developing classes.
- if a container is being used solely for ease of internal development such as event tie-ins, consider another approach.
- When making updates to things such as dimensions, positions, indexes, children, etc., consider ways to aggregate those updates into fewer calls.
- Check out ways to make use of direct calls to
invalidateDisplayList(), invalidateProperties(), and
invalidateSize(). Normally these are called indirectly via setter functions on their respective variables.
I am sure there are plenty of other means to improving performance as well.