Update On Box2D Performance vs. libGDX

A while back I posted a quick performance comparison between my Monkey port of Box2D and libGDX's JNI version. At the time the libGDX version was about twice as fast.

Since then I've done a bit of optimisation work and I thought it would be worth posting to note that I've just uploaded 1.0.12 of the port and to update the figures.

The Monkey performance on the same domino stack benchmark from the previous post is now ~88ms on average. Assuming that libGDX's Box2D implementation remains the same at ~75ms that means the performance gap has narrowed from 100% to under 20%. The variability of performance with the Monkey version is still higher, with spikes to >160ms where libGDX keeps it under 100ms but it's a much closer race now. Note that this is just a headline figure on a very collision/contact intensive example that is intentionally chosen for being slow on Android, performance in general is likely indistinguishable for the most part.

The performance improvements are significant enough to enable Monkey devs to target lower powered devices and/or create more physics intensive games. So, if you shelved something because the framerate wasn't quite there then it might be worth grabbing the newer module version and taking another look.

Monkey vs. libGDX Box2D Performance On Android

Note: The figures in this post are now out-of-date. I posted an update here.

The game I'm working on uses Box2D, or rather a port of Box2DFlash  to Monkey that I did. My game's use of Box2D isn't all that stressful but I have been curious as to exactly what sort of performance hit is entailed in using my port. In particular I've been curious about the cost on Android as that's the platform where things are tightest.

The problem with comparing these things is that it's hard to remove all uninteresting variables such as differences in the things being modelled or the costs of rendering and such. Today my curiosity got the better of me though and I downloaded the libGDX code, which compiles for Android and includes a version of Box2D accessed via JNI.

In order to compare like with like, I ported the most intensive demo from the Monkey test suite, which is a domino stack. I also fixed the update in libGDX's tests (which was oddly set to use frame delta-time, meaning that all the collisions failed if the frame rate dropped) and made the update iterations match the Monkey test standard. Finally I changed the timing code to only care about the update and to give values for the highest, lowest and average update times.

Here's the result (on my ZTE Blade running Android 2.3.7):

So we're roughly looking at a range of 65-100ms with an average of 75 ms. How does that compare to the Monkey port? The libGDX version is about twice as fast on average with the Monkey port running about 140-150ms per update. Monkey's variability is worse though and the worst case hits 300ms, so libGDX is even better in that regard.

Although that sounds like bad news, I'm less concerned now. The domino stack demo represents a scenario to be avoided. If your game relies on that sort of thing then today's mid-level mobile devices aren't really where you should be planning to release and certainly not without expecting to go native. I'm quite okay with half the speed in return for the ease of cross-platform development for my own needs.

That's not to say I'm happy to leave it as is. I doubt there's much more performance to wring out of micro-optimisations to the port but I certainly plan to revisit potential ways to remove the GC spikes. Another possibility is porting more recent code from the main Box2D implementation, but I've no idea if there have been any relevant performance improvements there.

There is one other potential source of a performance boost and that's if a native Android target is added to Monkey. I can imagine there are some headaches there with device compatibility and the like but for computationally intensive stuff like Box2D it could make a big difference.