Haxe compiled code performance
Asked Answered
R

2

12

How does Haxe compiled code compare in performance to its different targets?

For example, is PHP coming from Haxe faster or slower than original PHP code?

What about Javascript? Flash? C++? Etc.

Is there any serious benchmark out there?

Rodmann answered 14/8, 2013 at 0:55 Comment(0)
P
16

I don't know what benchmarks are out there, and it would certainly differ by target platform, so I guess this is only half an answer. But here are some general points:

  • If you search you can find several benchmarks comparing OpenFL/NME to Flash. One example is this one

  • For CPP, I am told things are slightly slower than regular C++. I imagine hand-optimised C++ could get quite a bit faster. An example benchmark from the creator of HXCPP here

  • For JS, I know Haxe sticks to relative best practices for performance. For example, the strictly typed nature of Haxe tends to result in the best performance with Javascript JIT compilers, so Haxe code is fairly comparable to well-written Javascript. (Note, I'm talking about regular JS here, not canvas / openFL graphics stuff - obviously that would require your own benchmarks).

  • For PHP, I'm not sure how Haxe generated PHP compares to hand written PHP. What I can tell you is that you can almost seamlessly switch from PHP to Neko (both run on apache easily) and you will get code much faster than hand-written PHP. Your bottle necks will come from DB access etc, not the code execution.

  • For flash, search around and you will probably find benchmarks. Haxe gives you some compile time features such as generics, type-safety and function inlining, which can help runtime performance.

Overall

The biggest performance gain with Haxe isn't from comparing it to the hand-written code in the same language, it's from being able to switch to a faster platform without much effort. Write in PHP, switch to neko -> huge speedup. Write in Flash, switch to OpenFL (C++) -> huge speedup.

Hopefully someone else can post some links to more relevant benchmarks :)

Promptbook answered 14/8, 2013 at 2:2 Comment(8)
Nice answer. I did however test and found that Haxe does result faster SWF performance comparing to same well written code in AS3 mostly due to compile time optimization. PHP coders have told me of some speed boosts thanks to strict typing, but you are 100% right - the bottle neck is rarely because of PHP, rather it's the DB processing.Evered
Thanks for your answer. If nobody provides more specific data I'll give the correct answer to you. What do you mean with "Write in PHP, switch to neko"?Rodmann
@CreativeMagic interesting regarding the compile time optimisations. I suspected so but I'm not a heavy flash user. Would still be interested to see some benchmarks if you know of any...Nopar
@Rodmann no worries, I'm hoping to see specific data too. What I meant was that PHP and Neko in Haxe have very similar APIs. The framework I use (ufront) compiles to PHP and Neko, as do Haxe DB Records, the web dispatcher and the sys package. The neko.Web and php.Web classes are almost identical. Unless you need existing PHP libraries or features, it will almost always be faster to deploy to Neko, and you can swap at any time.Nopar
@JasonO'Neil , well, it isn't so mysterious as Flash Player is doing a lousy job of optimizing anything on a real compilation level. For example: make a variable myVerySuperLongVariableName = 1; and i = 1; Run a loop to change data of variables and you'll see that i runs faster. Normal compilators would change all the variables to a, b, c etc. within the scope, but Flash didn't (not sure about now). I'll make a few SWF's to compare some essential stuff and post on my web-page later. I'll publish a link.Evered
@CreativeMagic It is actually not true at all. First of all, in flash(AVM2) string comparison runs in O(1), so it doesn't matter how long is your variable name. Second thing is inside a function variables dont have a name at all, they are assigned integer index(your swf/swc file doesn't contain variable names). Adobe flash compiler can be messing things up on completely different level though. And, just to finalize, haxe optimizations work on a different level too. Haxe compiler doesnt do a lot of job on real optimization, except for inlining, the gains are from proper typing, nothing else.Wardwarde
Hey @JasonO'Neil I just revisited this answer and found "both run on apache easily". Do you know how to install mod_neko easily on Apache? Because wherever I look, this does not seems to be straightforward.Rodmann
Hi @Pier, you're right, I'd forgotten the installation instructions aren't exactly straight forward. Compiling neko compiles the mod_neko2.ndll file, but you need to add the apache config yourself. I used these two pages to help me: haxe.org/doc/build/mod_neko and haxe.org/doc/build/mod_neko/jan_cheatsheet ... If you still have trouble ask on the Haxe mailing list and I'll try to write some clearer instructions for you there. Good luck! Once apache's configured it's fairly trivial to switch from using Haxe/PHP to Haxe/Neko.Nopar
G
2

You can look to this article. It compares the Haxe compilers. PHP seems to be the slowest among 5 target compilers. https://hal.inria.fr/hal-01356849/document

Godavari answered 21/5, 2017 at 11:13 Comment(1)
Don't hesitate to ask for more details. I am the author of that paper ☺️Godavari

© 2022 - 2024 — McMap. All rights reserved.