Practical optimisation

While browsing on Wonderfl to see how my cross product shader was doing I came across someone else's code, the evocatively named "forked from: flash on 2012-3-23". Running it I noticed it was slow: it was not doing much but got slower and used more CPU as it ran. So I decided to look into it.

Trig performance test

I have asserted that trigonometry is slow in a number of posts. The whole point of a post on Trig-free rotation blending is that trigonometry is so slow that it should be avoided. My reasons for this are my experiences on previous platforms, where trigonometric functions are often tens or hundreds of times slower than arithmetic operations.



But such assumptions often prove false on new platforms. Flash in particular does not have the highly optimised arithmetic operations of modern CPUs, so rather than trigonometry being especially slow it could be that maths in Flash is slow enough that there's no need to avoid Flash. This is certainly worth knowing, as there's no point avoiding particular functions if they are as fast as other ways of doing the same thing.

Flash isn't slow

Flash has a reputation for being slow, but one I think that is largely undeserved. It is not as fast as native code but is not that far behind, and compares favourably with other interpreted cross-platform environments.


But why does it have a reputation for poor performance? I think there are a number of reasons, all of which are pitfalls developers can fall into when making Flash games. Avoid these and it becomes much easier to make games which perform well across a wide range of platforms. So what are these pitfalls?

Half-angle formulae

The half-angle formulae are formulae from trigonometry with a variety of uses. One important use is for optimising trigonometric calculations, of the sort often used in 2D geometry. In particular calculations of the form


fSin = Math.sin(fAngle);
fCos = Math.cos(fAngle);


can be done more efficiently.

Another screenshot

Busy again, so just another screenshot. This maybe gives a better sense of some of the things in yesterday's screen shot. Lots of fun figuring out how to do [dozens of] smooth, multicoloured particle trails without killing a 60fps frame rate.

Fast path member access

I noted on Wednesday that accessing members by repeatedly doing a lookup in a Vector is slower than doing that lookup once. But it was slower even than I expected. The code was doing the lookup eight times more than necessary, but was over twelve times slower (i.e. it took over twelve times as long). So I forked the code and re-wrote the tests to find out what was going on. The results of this are especially interesting.

Notes on testing

A couple of notes on the performance tests I've been doing.

Dereferencing array members

The title refers to code like this


iSum += aData[iIndex];


Looking up in an Array (or Vector) requires the code to find the address of the object or value requested then retrieve whatever's at that address. It might also check whether it exists, and whether it is in range (and if not whether it should grow the Array or Vector to accomodate it).

Accessing members by name

One sometimes misunderstood feature of ActionScript is that as well as accessing members of a class directly and using accessors it's possible to do so using the name of the member, passed as a String to the class. Misunderstood as there is a right way to use this and a wrong way to use this. And the wrong way is incredibly slow, so much so it should be avoided at all times.

setter perfomance test, conclusions

So far the accessor tests I've been doing have only been of getters, or more generally of accessor functions for retrieving members from classes. The obvious question is whether setters have the same performance penalty. The answer is yes, they do.

getters and built-in classes

Following on from yesterday's post, an obvious question is whether getters and setters are used for built in classes. The answer is yes, but not for all of them, and it is important to know which.


I won't post code for this, as the code is straightforward but lengthy, and is easily inspected at wonderfl where I've created this program to demonstrate it. It defines two classes, one derived from Vector3D, one derived from Bitmap. The purpose of each is to compare accessing the built-in members of the classes with members added by the derived classes.

getters and setters are evil

ActionScript has a feature which I have not seen in any other programming language: getters and setters. These are special member functions which when used can be called like direct member access. In some ways this is like operator overloading in C++, except C++ does not allow the '.' operator to be overridden. Having seen how this works in ActionScript it seems like one innovation other languages should not copy.

Accessors are slow

This is the most important performance optimisation I learned writing ActionScript. It provides a significant performance boost, and in class-based code arises more often than almost all other optimisations. It also flies in the face of what I learned as a C++ programmer.


In C++ accessors are key to good programming practice. Their main use is to hide the implementation from the interface of a class, so the class can be updated without code using it having to be re-written. They make it easy to add code to record accesses for e.g. ref-counting or debugging purposes. Making members private and providing accessors for them documents the code as it indicates which members are safe to access directly which are not because they e.g. have side effects.

On Optimisation

This is not about any one optimisation approach but about my overall strategy. It might answer some questions readers have, or at least address concerns I've seen raised elsewhere.

A faster random

Although ActionScript has its own random number function, Math.random(), like most library calls it is not especially fast. But it is easy to replace, to provide a significant speed up, as well as make it easier to do other optimisations.


The basic idea is very simple: instead of calling Math.random()while the game is running call it a number of times at startup to populate a list, then at runtime pull values out of that list. This would not work in all games: it might produce predictable or repetitive outcomes in some cases. But in games where random numbers are used for effect or to provide some variability in a number of ways it is often indistinguishable from Math.random() (which is not truly random anyway).