explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Quick Performance Tip for Flex

2 Comments

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.

Advertisements

2 thoughts on “Quick Performance Tip for Flex

  1. At 360Flex there was a session on the Flex Framework and Deepa Subramaniam said pretty much exactly what you found out the hard way. Don’t use any more containers than are necessary. She explained how containers size themselves and how that chain may have to repeat itself if children change their size and so on. It can become very inefficient. When the presentation slides are up at 360Flex you should take a look at her session.

  2. Nice blog, Very useful information here, Thanks for sharing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s