How about a performance test suite for all Haxe frameworks

488 views
Skip to first unread message

Robert Konrad

unread,
Aug 19, 2015, 2:41:42 PM8/19/15
to Haxe
So Dmitry Hryppa is currently torturing lots of innocent bunnies to talk us all into improving the performance of our frameworks: http://themozokteam.com/playground/frameworkstest/ The end justifies the means they say and I tend to agree in this case. Drawing the same bunny over and over again is an interesting performance characteristic (because it resembles for example particle systems and tilemaps). And believe it or not, the biggest change that was made to draw more bunnies in Kha was a fix in the Haxe compiler for constructor inlining by Simon and everybody can now benefit from that.
But there are many many more performance characteristics of a media framework than just bunny drawing that shouldn't go untested. Also there are many more systems than a Windows PC with a beefy graphics card, that shouldn't go untested either.
So I discussed that a little with Lars Doucet already and I would like to suggest that we all work together to set up a big performance test suite for all Haxe frameworks. We should include Non-Haxe frameworks, too, just like Dmitry also does - I think that is really great, gives everybody a much better perspective about where we are performance wise.
The "test on many systems" part of that is kinda hard, but building the test suite itself - not so much. If Dmitry agrees we could just take his stuff, setup a Github project (maybe even let Dmitry manage that, if he would like to do that?)
 and take pull requests. We could basically implement a process where whenever somebody wants to test a specific performance characteristic of a framework (can very well be the framework developers themselves) sends in a pull request for that - and when the developers of some other framework want to participate in that specific test, they port it and send a pull request themselves. When all those tests just output a performance number when run, statistics could be created automatically for all tests and be updated regularly on a webpage.
So, how about that?

Lars Doucet

unread,
Aug 19, 2015, 2:47:07 PM8/19/15
to Haxe
It sounds good to me; and honestly doesn't take a lot to get started. 

This method also seems to address the usual issues with isolated benchmarks (not providing source code for your tests, only running on one machine, only running one narrow benchmark that doesn't have much real-world relevance).


Robert Konrad

unread,
Aug 19, 2015, 2:47:30 PM8/19/15
to Haxe
And thinking about the "many systems" aspect - if we can make it really easy to run the tests, we can maybe crowd source the results?

Khaled Garbaya

unread,
Aug 19, 2015, 4:09:46 PM8/19/15
to Haxe
I really like the idea but it would be nice to mention the in which platform the test was done and for OpenFL benchmark was it normal display list or gpu accelerated display list

Dmitry Hryppa

unread,
Aug 19, 2015, 4:18:14 PM8/19/15
to Haxe
Cool :)
No problem, I will publish all sources and binaries of my bunnymark on GitHub soon.
Will let you know guys when this mission will be complete.

Dmitry Hryppa

unread,
Aug 19, 2015, 4:38:08 PM8/19/15
to Haxe

Dmitry Hryppa

unread,
Aug 19, 2015, 4:54:30 PM8/19/15
to Haxe

Lars Doucet

unread,
Aug 19, 2015, 5:02:47 PM8/19/15
to Haxe
Great Dmitry!

Could you start a new repo that we can organize an entire benchmark suite in?

I figure it would look something like this:

(root repository)
--> bunnymark
-----> kha
-----> nme
-----> openfl
-----> heaps
-----> luxe
-----> (etc)
--> someOtherTest1
-----> kha
-----> nme
-----> openfl
-----> heaps
-----> luxe
-----> (etc)
--> someOtherTest2
-----> kha
-----> nme
-----> openfl
-----> heaps
-----> luxe
-----> (etc)

On Wednesday, August 19, 2015 at 3:54:30 PM UTC-5, Dmitry Hryppa wrote:

Dmitry Hryppa

unread,
Aug 19, 2015, 5:16:17 PM8/19/15
to Haxe
Sure :)

четверг, 20 августа 2015 г., 0:02:47 UTC+3 пользователь Lars Doucet написал:

Robert Konrad

unread,
Aug 19, 2015, 5:27:54 PM8/19/15
to Haxe
Wonderful. And off we go.
Next I think we should try to automate test runs as much as possible. For rendering tests we should measure time, so that would change the bunnymark slightly to something ala "rendering one million bunnies takes xx milliseconds". And beware - we want to also test stuff on JIT-Compilers, so warm up phases are important. Can prepare a pull request for the Kha bunnies.

Justin L Mills

unread,
Aug 19, 2015, 5:44:32 PM8/19/15
to haxe...@googlegroups.com
It would be nice to see Starling AIR - Haxe Openfl, or AS3 versions within the tests, it's important that Adobe realize that Haxe is a good target for thier tools, such support would open many opportunities for developers still using AIR to allow them to use Haxe instead. FlashIDE is a brilliant tool which has always lacked export options.  It is also very important to smoothing integration of Haxe with photoshop and illustrator.   It's not that Haxe is not amazing despite corporate support, but, ...  it is often a limiting factor for developers, and limits coding choice for work projects, and more graphics support from Adobe, could make a real difference to the number of corporate and design agencies interested.
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

Lars Doucet

unread,
Aug 19, 2015, 5:49:14 PM8/19/15
to Haxe
Are you volunteering? :D

Hugh

unread,
Aug 19, 2015, 9:46:22 PM8/19/15
to Haxe
I would also like to see stuff less related to the framework, and more about the target, eg a physical simulation.
So we can compare JS vs hxcpp vs java vs c# for this aspect, orthogonally to the rendering/framework.
This would make performance improvements to hxcpp easier and more likely to happen.

Hugh
Reply all
Reply to author
Forward
0 new messages