Stephen Calender Programming Blog

Not everyone needs to worry about writing the most optimized code. In fact, if you are programming Flash websites or small projects you probably should not be concerned with it – some would even argue that it would be inefficient since more optimized code takes more care to write. However, there are those projects that are large or complex enough that it is essential, and many times, we have a very vague idea of where to draw the line between simple and complex. Scopes of projects can change and grow requiring different performance needs. Then, even on small projects, there can be times when the frame rate suddenly drops and we need to hunt down the cause and procure a solution. Whatever the reason, when the need to optimize arises it can be a difficult and time-consuming process.

I was in the middle of a large Flash project for Semiotic Technologies and it started to act lethargic, as there was still a significant amount of work left to do, I looked across the web trying to find any significant research into Flash optimizations. Most large programming and graphic software systems either let you have the source code or have profiling tools that come with them, Flash has neither. There is some information scattered about on other flash forums but the credibility ranges from complete assumptions and unsubstantiated claims to ‘here is some code I executed once and this is how fast it went’. Since we were in the middle of development, I did not have time to test all the optimization practices I had found. I did what most people do in my situation; I did my best to target the slowest code, made some changes and observed if it acted any better. Unfortunately, unplanned optimization is a common trap that catches most programmers at some point or another. Then we have to make a judgment call on where we think the most time is being spent and how much time we can budget to making it run faster. I was in trouble when it was difficult to find accurate performance information on the web.

I got through that project, but it raised many questions as to what is fast and what is not in ActionScript 3.0. As I was going to be programming many more projects of a similar nature, I vowed to get some concrete answers before the next development cycle. Then, besides writing faster code to begin with, the next time I found myself working with lethargic code I would be able to target and optimize much more quickly. Of course, the corollary to writing more optimized ActionScript is that your Flash application can be more sophisticated and available to a wider audience (after all we do not all have shiny new computers, and optimization is going to be even more important for phones and other mobile devices). In this pursuit of knowledge I ran over 70 speed tests on performance inquires I had read on the web and of my own interest.

Before we get into the real number crunching, I have some general advice and words of caution. Get a working solution before you try to optimize, if you do not trust me yet, trust Hoare and Knuth – “Premature Optimization is the root of all evil”. As I already stated before, optimized code takes extra care and time to write, rarely do you have the luxury of optimizing all of your code, nor is it an efficient practice. Spend most of your optimization energy on the code the runs the most, and if you do not know where the most CPU time is being spent, it is worth your while to find out. “Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you have proven that’s where the bottleneck is.” – Rob Pike. I still remember one of my college professor’s anecdotes “10% of your code runs 90% of the time”, odds are there is a very small portion of your code that you can optimize to get big results, you just need to know where to look. Cleary for and while loops as well as onEnterFrame functions are prime hunting ground for optimization, but the most expensive task by far is rendering. I will go over some ways you can optimize rendering and artwork, but how many objects you have on the stage – and how many of those are animated or are alpha renders – should be the first place considered for optimization.

Continue to Methodology

This post is part of a series:
Introduction <– You are here
Methodology
Operation Speed
Data Structure Speed
Graphics Speed
Results