Practical Performance Tweaks

I’ve had a little bit of time on my hands in my day job *cough choke laugh* and thought I would spend some time doing some low level improvements on the performance of my applications. Though there were some changes I made that might have improved the performance of a function by a few milliseconds on average there were a few things that I changed that made large improvements. These are the sorts of fixes that you commit to memory and just always keep them as time moves forward.

I’m not talking about making sure that you removeEventListeners and nullify unused objects for garbage collection, that is a given. These are common tweaks that people could use in every application but often we don’t because we suspect that the performance hit isn’t as big as it is. Here we will look at how big that hit actually is.

For all these tests I used Grant Skinner’s Performance Testing Harness. The numbers for the tests are provided along with the source code and the test available to run. I slightly modified the Testing Harness so that I could also get the times and numbers out of each test for graphing purposes.

Array vs ArrayCollection vs ICollectionView
These tests all started when I wondered how much slower iterating through an ArrayCollection was than iterating through an Array. The numbers were staggering. In some cases, iterating through the Array was 1/50th of the time or 5000% faster.

For my test I also was curious if using an interface instead of using the actual object made a difference. As you can see from the numbers that the difference wasn’t hugely significant, but actual.

One rumor that I heard was that ArrayCollections are faster at finding a specific index value than Array’s due to some sort of magical optimization. So I tested that rumor also, below are the results. As you will see, this rumor is false. Arrays are faster at accessing a specific index value than ArrayCollections.

Already there are additional tests I am thinking about running, but on the whole you can see that using the base Array over ArrayCollection will yield large performance improvements.

However, I again want to point out that whenever you set an Array as the dataProvider of a Flex component, Flex components convert Arrays to ArrayCollections. So don’t try to get a performance increase from a component specifically by setting the dataProvider as an Array, the Array will be transformed either way.

Loops
The next section that I was going to test was the age old debate about the perfect loop: For Loops vs While Loops, iterating before the loop vs after the loop, etc etc. Luckily for me, as soon as I started looking at Grant’s testing harness, he had already created most of the test cases for me (Thanks). So the only extension to the test that I had to make was to also test against iterating before or after the loop (++i vs i++). The results can be seen below.

What you will probably notice is that no specific loop includes massive performance improvements, though the simple for loop seemed to be the fastest on average. So take your pick and run with it.

Unrolled Loops
The next tests that I came up with was to see how efficient rolled vs unrolled loops were. The reason I felt this was important is there are times that we needlessly iterate through a loop when we know there will always be X number of elements. When this is a the case I’ve found (and the tests prove) that it is faster to just do what you need with the X elements rather than write a loop to iterate through the elements.

Remember to check the source to see the implementations of these different tests.

Length Reference Variable
This is definitely a nit picky test, but I had to know the truth! When iterating through a loop is it significantly better to get a reference to the length of the loop, or is it okay just to use array.length in each iteration. As proven, using a variable to store the length is significantly better.

Reference Variables
When iterating through a loop I often like to pull a reference to the current value that is being evaluated in a loop. I do this mainly to make reading the code easier, but I was curious if this creation of a new reference would be harmful to performance. On top of that I was curious if giving these temporary variables a type was helpful for performance or not. Below are the results.

As you can see I’ve figured that there isn’t a significant performance increase or loss with using temporary variables. I think I’ll keep using my temporary variables to make reading easier.

Type, Cast and toX
The next series of tests are extremely geeky tests with some startling results. Is it faster to say (object as String) or String(object) or object.toString? This test case and many others are included below for each of the base types. May this help you decide how to type and cast your variables.

The big one to notice is the amount of time it takes to String(number) instead of saying (number as String).

Included with each test is the control case of casting and typing each type to the same base type.

Remember when using “as”, if the conversion fails, you will receive a null rather than the value. Unless you explicitly know what the type will be, it is always good to make this check.

The “new” operator
I’ve always been told that when creating a new base type that you should use the value rather than new because it saves the need for the VM to allocate the memory in the heap. But what was the ACTUAL performance improvements. Again, the numbers are staggering. For the next tests I created each of the simple types 3 different ways.

The first way I used the new operator as such: var s:String = new String();
The second way I used the new value as such: var s:String = “”;
And the final test was to create the variable with the new operator without the final parenthesis, such as: var s:String = new String;

For every test setting the value rather than using the new operator was almost twice as fast. The biggest difference being with creating a new Array, using the [] operand instead of the new operator was almost 3 times as fast.

I should also point out that for almost each test, using the parenthesis was slower than leaving them off when creating a new variable, though this is considered bad practice. Though the difference was marginal.

Static Methods vs Class Methods
As a side curiosity I was wanted to know if there was any performance loss or gain based on the types of functions used within a class. I was able to see that there weren’t any significant performance improvements over one type of function or another. So stick with best practices within your classes and only make methods and properties public when they absolutely have to be.

This test does not include testing whether creating the class and then accessing the function is better than a static function which does not need to instantiate a class.

Using “this” and Other Class Curiosities
This next section includes many different tests to improve my class creation.

Setting the default values
In this test I was curious if it is better to initially set a variable in the constructor or at the variable, and also if setting the variable defaults inside the class vs outside the class was better. What I found is that it is faster to initially just set the variables to their default value rather than making this change in the constructor.

Is using “this” wrong?
Checking whether it was faster to use the “this” identifier was harmful to performance I concluded that there was no significant performance loss or gain in using the “this” identifier.

Getters and Setters vs Direct Accessors
Lots of good ole’ boy Java developers will tell you that every property has to have a getter and setter. Other programmers will say that this is only necessary if there is some logic that needs to run in the get/set process. Now you can see that by using a getter/setter when a direct accessor can be used is wasteful for performance and typing. Therefore, only create getters/setters when it is important to run some logic in the getting/setting process.

Size really doesn’t matter… in variables.
Finally, the stigma from writing Javascript applications always left me feeling guilty about using full words when a letter can do. In Javascript this was a performance issue and caused many programmers to use single incomprehensible letters instead of easy to read words. To elevate my guilt I decided to test if using long variable names made any difference at runtime. The answer is no. No savings, no loss. Now, guilt free, I will always use well written variable names instead of short single letter descriptors.

If..Then vs Switch..Case
Like loops, developers argue which logical test is better: if..then vs switch..case. Pitting the two against each other, apples vs apples, I’ve found that if..then statements are slightly faster than switch..case statements. I will still use each statement where appropriate though, but it is good to know in the situations that I have the choice that I should use if..then statements.

Math.max() vs Math.max.apply()
One little known secret to AS3 is the apply method. Most classes have more than one way to skin a cat, and the apply method is that function. In the case of Math.max (or Math.min) I was curious how much faster the apply method was vs logically finding the largest (or smallest) value. The numbers were staggering. From now on I will be using the apply method whenever possible as it is a very low level and fast function.

Final Thoughts
Obviously the things in this list I see as some of the greatest offenders and also the easiest to fix. It all comes down to you and which changes you feel comfortable making in your daily coding practices. Some of the more “nit picky” performance changes I feel can effect code readability and reusability, and which you implement into your code is up to you and your coding practices. Hopefully this ends the debate between some techniques as being the end all be all technique.

If there are other coding techniques that have left you wondering which is better, let me know and I’ll add it in. I’m sure over time I’ll revisit these test cases.

The Test, Run It For Yourself Or View Source

View Source (or right click swf)