Mindless Labs dev blog

JsUnHaXe - Javascript cleanup for Haxe

When developing flash games, you often need different architectural components: the game in flash, a server for save states and high scores, and maybe javascript for integrated flash-and-html user experience like status messages on the web page reflecting in-game events.

Haxe is a swiss toolkit language: write all your code in haxe and then compile to different platforms like neko or php (for the server), flash or javascript. Now I will consider the javascript target.

Haxe and multi-file javascript

When compiling to javascript, you often would like to separate functionality into a common core and smaller modules. However when compiling with Haxe, it will generate all the core data into the sub-modules too (well, this is not a precise description of what is happening, but let's stick with it for now).

Fortunately it doesn't seem to be hard to decouple the modules from the core. I wrote a small python script that I call JsUnHaXe, which removes redundant entries from generated js files. Download and try it using python jsunhaxe.py out_dir my_core.js my_core_ext1.js. Note that sub-modules, sub-sub-modules, etc. can be passed, in this case the Kth output file will lack all entries beginning from the first and up to the K-1th input file.

Happy Haxing!

09.10.27. 16:42 - | four comments - § ¶

Tags: haxe javascript multiple_files python tools

Haxe serializer speed

The serializing feature of Haxe can be very handy - for example using Haxe Remoting in a flash game to communicate with your server, Haxe objects are automatically serialized on the client (converted to textual form), sent over to the server, and unserialized to object form. However the speed of serializing does matter.

The serializer not only serializes the object passed to it, but also automatically follows and serializes references to other objects. As an example, if you pass the root element of a tree structure for serialization, it will follow the links to the child nodes and as a result serialize the whole tree. This is very fine, but if the objects contain cyclic references - like child nodes linking back to their parents - the serializer would run into an endless loop.

For avoiding this, the serializer has an option called useCache, which when turned on, the serializer keeps a memory of previously met objects and won't re-serialize them. Unfortunately, for technical reasons the lookup of an object in this memory takes O(n) time, n being the number of objects met while serializing, so the full serializing takes O(n^2) time.

This means that if you are keen on speed, you must not use the useCache option, and take care of serializing structures without cyclic references. And, unconvenient as it is, but sometimes you may have to consider going down to the level of (un)serializing by hand, which would enable for highly tuned speed.

09.10.17. 23:13 - | one comment - § ¶

Tags: haxe serializer speed