[Gama11]

Neko isn't that fast, since the bytecode is dynamically typed. That combined with the fact that it's not really actively developed anymore, you'd probably be better off checking out its successor called "HashLink" instead (see comment thread above).

Btw, a JVM target (generating JVM bytecode directly) was recently merged into the Haxe compiler. Previously there was already a target that generates Java source code, but that had some issues like slowing down compile times with the native Java compilation step that needed to be done.

[logicprog]

Yeah I was concerned reading that, about boxing everything due to dynamic types.

[johnday]

Why would types speed up the code?

[mratsim]

Without types everything is a pointer (boxing), and when you actually need the value you need to resolve (dereference).

This is almost always cache miss.

If the collection is polymorphic it's even worse because you dereference to access the dispatch table which then redirects you to the real value.

Furthermore, each variable will need heap allocation and tracking, stressing the garbage collector and the underlying allocator (unless you preallocate big chunks like Java).

[cygx]

Static types avoid the cost of runtime type checks and dynamic dispatch.

[naasking]

Also they permit more inlining opportunities, allow eliminating more dead code, and more. Types almost always improve program performance.

[Gama11]

The "HashLink in-depth" blog post talks about this, an excerpt:

> [...] Neko is very slow. The main reason for this is that it's dynamically typed. So every "value" in the VM can be either an Int, a Float, a Bool, some Bytes, an Array, a Function or Object, etc. And because this value needs to be recognized at run-time, its type together with its data need to be stored in the memory. [...]

https://haxe.org/blog/hashlink-indepth/