Menu

Subscribe

Bunnymark Adventures

Menu

I've spent a few hours porting the basic bunnymark to luxe and I thought I'd share some findings. I will start by recognising that Sven didn't see much point in doing this from a performance testing perspective for snowkit at this stage so don't take any of this as an indictment of the potential. I mostly did it as a way of understanding the basics of the luxe scene-entity-component relationships. That said I think the results are somewhat interesting, especially to me as someone who has barely dabbled with Haxe.

I won't go into the headline bunny count at 60fps as it's unsurprisingly not great but the profiling results on javascript (Chrome) perhaps are:

So here we've got the initial results with a couple of thousand bunnies. Sven mentioned the geometry batcher as a performance bottleneck in another post so I was expecting that but, skipping over the gc for now, the hit coming from accessing StringMaps wasn't. I'd noticed that StringMaps were commonly used throughout luxe for a number of core systems, but over 15% total processing time is a bit much.

It turns out that the Haxe JS implementation for StringMaps is less than optimal. I'm no Javascript expert but it appears to iterate over the values by first creating an array of the keys and then iterates over that to retrieve each value (and concatenates a string each time into the bargain). Fortunately, the Java and C# implementations seem to have had more thought put into them so I quickly ported one of those to work in JS and:

The StringMap accesses dropped out of sight and I got back ~5fps on my laptop.

I did try a build for desktop and that was actually slower than the browser. A quick peek at the StringMap implementation for C++ looks rather similar to the JS version so I'll be curious to see if that's as much of a performance issue.

I guess the worrying thing about this for me is that I'm finding these issues in base library files for the tech stack. I just hope this is an odd edge case for Haxe.