# Benchmarking gotchas

Just a quick tip to get the numbers right when testing the execution time of your ActionScript code; you only get correct results if you follow two steps:

1. Compile your code with the debug flag set to false (mxmlc: -debug=false). Otherwise your swf gets bloated with byte code used by the debug player.
2. Always test your swf with the release player. Most developers have set the debug player as the default one, but it doesn’t reflect real world performance because it can be much slower. If the context menu has the option “show redraw regions” you are running the debug player.

If you are not aware of this you might unintentionally spent much time in implementing some clever optimizations which appear to run faster in the debug player, but perform worse in the release player. Here is an example for the sin/cos approximation:

 Debug player Release player Math.sin() + Math.cos() 340 ms Math.sin() + Math.cos() 142 ms inline sin + cos approximation (high precision) 440 ms inline sin + cos approximation (high precision) 11 ms time in milliseconds needed for computing sin and cos @ 1.000.000 iterations, may vary on different platforms

## 11 thoughts on “Benchmarking gotchas”

1. Hey! These aprox. for sin e cos are awesome!

I shifted some code lines of the low precision approximation and ended up with a 15%/20% faster version than the other post! Same test 1.000.000 iterations for norma-code and modified-code.

The trick is to reduce the number of multiplications in the “sin” and “cos” and avoid unnecessary “if” clauses.

Here it is:

//always wrap input angle to -PI..PI
if (x 3.14159265)x -= 6.28318531;

if (x 1.57079632) x -= 4.71238898038; else x += 1.57079632;
cos = x * (1.27323954 + 0.405284735 * x);
}
else
{
sin = x*(1.27323954 – 0.405284735 * x);
if (x > 1.57079632) x -= 4.71238898038; else x += 1.57079632;
cos = x * (1.27323954 – 0.405284735 * x);
}

Thanks for this technique!

2. Forgot the XHTML… :)

``` //always wrap input angle to -PI..PI if (x 3.14159265)x -= 6.28318531;```

``` ```

``` if (x 1.57079632) x -= 4.71238898038; else x += 1.57079632; cos = x * (1.27323954 + 0.405284735 * x); } else { sin = x*(1.27323954 - 0.405284735 * x); if (x > 1.57079632) x -= 4.71238898038; else x += 1.57079632; cos = x * (1.27323954 - 0.405284735 * x); } ```

3. Thanks for the advise. I do suspect I’ve done optimalisation that might not be properly tested in the release version.
BTW, this is the kind of interesting actionscript details I love to read about as I seldom have time to explore and test them myself. Keep up the good work.

4. The piece of code I put in the first comments are all wrong… If you don` mind delete that..

I`ll post in my blog a note about your technique and put the code there!

If you have more optimizations techniques I`d might be interested!

Thanks!

5. Peter says:

Do you know if code optimisations proven using the Flash IDE will be equally relevant to code compiled with mxmlc or compc?

6. hi, same compiler so it doesn’t matter. and the debug flag is only set if you debug the swf inside the IDE.

7. Peter says:

Thanks, that’s useful to know.

8. William says:

I’m a Flash noob using CS4. When I build a project in debug mode (Ctrl+Shift+Enter), it is clear, but when I build it in normal mode (Ctrl+Enter) the context menu has “Debugger” grayed out and it runs faster, but it _does_ still have the Show Redraw Regions option. Does this mean that the SWF still has some debugging options turned on? If so, can I turn this off in CS4?

9. @william this just means that you are running the swf without additional debug byte code inside the debug player.