OpenFL Haxe performance tests

Wanting to gain some perspective on OpenFL Haxe performance, I applied some tests previously used to research Flash performance. Still primitive, I thought I’d share some preliminary results here for those interested. Future updates and additional details will be available via my blog.

Initially, I wanted to see metrics on desktop runtimes; so, the following platforms are being evaluated:

  • Mac — Native Mac 64-bit assembly
  • HTML5 — JavaScript target running in Chrome 39.0.2171.71 (64-bit)
  • Flash (Haxe) — Flash Player, executing bytecode compiled by Haxe
  • Flash (AIR) — Flash Player, executing bytecode compiled by Adobe AIR SDK
  • Flash Pro — Flash Player, executing bytecode compiled by Adobe Flash Pro
  • Neko — Haxe Neko compiler

There are multiple comparisons that can be made. For one, performance can be compared between platforms - native Mac, HTML5, Flash, and Neko targets. Also interesting is variance within Flash runtime, comparing performance of bytecode generated by different compilers.

Tests run on a MacBook Pro running Mavericks 10.9.5, 2.4 GHz Intel Core i7, 8GB 1600 MHz DDR3. Environment:

  • Haxe toolkit 3.1.3
  • hxcpp: [3.1.39]
  • lime: [2.0.0]
  • openfl: [2.1.6]

All times in milliseconds - faster is better

Sprite instantiation test

Average time to instantiate a new Sprite, executed 1,000,000 times.

new Sprite();


Point instantiation test

Average time to instantiate a new Point, executed 1,000,000 times.

new Point();


Event dispatching

Average time to dispatch and handle an event, executed 1,000,000 times.

dispatchEvent(new Event(Event.CHANGE));

Event listener added as:

 addEventListener(Event.CHANGE, callback);
 function callback(event:Event):Void {
     // do nothing


Collection push

Average time to push a string literal into a Vector and Array, executed 1,000,000 times.

v.push("Hello, World");

Vector: Strong type (blue)

Vector in Haxe defined as: var v:Array<String>
Vector in AS3 defined as: var v:Vector.<String>

Array: Dynamic Type (red)

Array in Haxe defined as: var v:Array<Dynamic>
Array in AS3 defined as: var v:Array

Vector vs array perform nearly equivalent in this test, except for Mac 64-bit native assembly, which shows overhead of dealing with dynamic types.


Type casting

Average time to cast a MovieClip to a DisplayObject, executed 1,000,000 times.

Cast: (blue)

Haxe defined as: var obj:DisplayObject = cast mc;
AS3 defined as: var obj:DisplayObject = mc as DisplayObject;

Safe cast: (red)

Haxe defined as: var obj:DisplayObject = cast (mc, DisplayObject);
AS3 defined as: var obj:DisplayObject = DisplayObject(mc);



This is really amazing to see, way more interesting than I expected

Great post, Jason,

I still remember your post at stackoverflow:

I wish you could do more testing and put together some tips for OpenFL users with different targets, I’d love to get some extra tips from you how to optimize for Android and iOS :smile:

1 Like

HaXe execution speed has always been stellar when measured this way. I’ve had the sense (surely outdated now - this was years ago) though that whatever HaXe was doing didn’t match the GC strategies as well as AS3 (or at least that was my guess), because it seemed to suffer from more pauses and hiccups - especially on older AMD based CPU hardware.

I’d really love to see something comparing memory usage and GC pauses over time between HaXe and AS3. This is one of the hardest things to deal with in any memory managed language, and it’s IMHO more important than raw executions speed. It might even be nice to compare it with something like mono (maybe using the HaXe C# compile target).

@jasonsturges blog link 404’s

@GimmickyApps This post is from almost 2-years ago, and my interests are within other technologies.

Per 404s on my site - yes, that’s the expected result.

This project is still available through GitHub:

Ah, thanks for the update :slight_smile: