The game code was heavy on maths, so I have decided to pinpoint where the difference in performance is coming from. I found an AS3 performance test on [AS3 performace test](http://www.onflex.org/perf/) and ported it to hAxe – again, not necessarily perfectly.
You can check out the results here:
* [AS3 test](/?page_id=11)
* [haXe test](/?page_id=8)
The tests can be seen at [http://www.onflex.org/perf/srcview](http://www.onflex.org/perf/srcview).
As you can see, the haXe code is slower – sometimes a lot slower – than the AS3 code. Of note:
* Test 2 : sort. This is perhaps not surprising because the haXe version is using a custom string compare function, rather than a built-in one.
* Many of the functions are to do with string manipulation. I suspect the probelms here are introduced though the layering of the library via “Std.” and the internal string functions.
* Function 9, the loop code, shows a huge difference. Here I think there must be some loop optimisation that hAxe is missing out on.
* Function 12, a subroutine call, is also very very slow. I think there may be something simple that haXe is not doing.
So there you have it. Loops and function calls – building blocks of most programmes, are very slow.
These differences are way bigger than the file-size differences would suggest, so I think there is still hope that haXe speed can be greatly improved.