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.

Variable speed rotation with complex numbers

I wrote only last week that complex numbers are best for mostly fixed or uniform speed rotations. This is true in general, but there are ways to use complex numbers when the speed varies, as long as it varies in a straightforward way. In particular if the speed increases linearly, so with uniform angular acceleration, it can be modelled with complex numbers.

Angles

Recent posts have focussed on how to avoid angles when programming. The reason for this is simple: angles are slow to work with. In particular the trigonometric functions used to work with angles are expensive compared to arithmetic operations. There are times though when it is impossible to avoid angles.

Accuracy

I came across a few issues related to accuracy in my ballistics app, both expected and unexpected. As these have wider application than ballistics simulations and are interesting in their own right I thought them worth their own post.

Varying the rotation speed

One objection to rotating using complex numbers instead of angles is that it works best with a fixed rotation speed. This is correct: if the speed needs to vary from frame to frame then the 'delta' needs to be recalculated each frame, and it may be easier to just use the angle to calculate the rotation each time.

But as long as the speed is mostly fixed complex numbers work well. If for example the rotation speed changes in steps, but between these is constant, then the 'delta' needs only be recalculated at these steps.

Trig-free rotation blending

As mentioned yesterday complex numbers can be used to do rotations in two dimensions, by just multiplying by a suitable (complex) value. One particular application is rotation blending or interpolation, where the direction of something is blended smoothly over time. An example would be aiming a gun, where having it move over time to aim is more realistic and interesting.


Normally this would be done by blending angles, so an angle is updated in steps from one direction to another. But this is expensive as two trigonometric calculations are required each frame to update the direction or to transform whatever is being rotated. It is quicker to use complex numbers and avoid trigonometry altogether, except at the start.

Complex numbers

Complex numbers are a much under-appreciated topic in mathematics, or at least that's how it seems to me looking back on them. Very often they are introduced almost as a mathematical exercise, as a way of solving mathematical problems such as quadratics which are otherwise insoluble. But once this is done all it gives is an impossible solution.


For example in my ballistics application complex number solutions to the quadratic formula in it (given by a negative discriminant) arise when the target is unreachable. And many applications of complex numbers seem like this. Except the more you study mathematics and physics the more useful they become, arising in diverse areas such as dynamics, electro-magnetism, and quantum mechanics.