When we port Unity to new platforms, it is always an important question to find out how well it performs on that platform – and to see what we can do to make it perform as fast as possible.

One exciting new platform we are currently working to support is WebGL. WebGL is unique when it comes to performance: all code needs to be cross-compiled to JavaScript; some common performance-enhancing techniques, like multi-threading and SIMD, are not available yet; and we are relying on a completely new scripting runtime, IL2Cpp, to run user script code. So we need to find out: Will it be fast enough to play games? How will different browsers and hardware compare? What build settings will produce the fastest results?

These are the questions we have asked ourselves, and we have frequently been asked by our users as well as by suppliers of WebGL implementations. The most obvious approach is to run existing Unity content in WebGL and measure the frame rates. We found that, for most of the content we’ve tried, frame rates are at least 50% of native builds (depending on many factors, such as the browser being used). You can try two demos of games exported to WebGL here. However, we would like to get precise and reliable numbers. Which areas are particularly slow in WebGL? Which are fast? How do different implementations compare, exactly?

To find out, we have created Unity Benchmarks, a suite of benchmark tests written in Unity. The benchmarks stress different areas of the engine and produce easily-comparable numbers on performance. Click here to try Unity Benchmarks in WebGL in your browser! (Note that some WebGL implementations on windows may get incorrectly high results for the Mandelbrot GPU benchmark, as they won’t render the shader correctly. We are investigating the issue and looking for a fix.)

Unity Benchmarks has different tests stressing 3D physics, 2D physics, particles, navigation, animation & skinning, object instantiation, scripting, draw calls and GPU pixel throughput. Each benchmark will count how many iterations of a given task Unity can perform in a fixed amount of time. For the reported numbers, higher is always better.

If you run all of the benchmarks, it will also show an Overall Score value. This score is calculated as a weighted sum of all the individual test results. Since the different benchmarks have very different result scales, they each carry different weights in the overall score. The weights are calibrated to produce similar result scales on my development machine running in WebGL. But that is somewhat arbitrary, so, when comparing results, the individual scores are much more meaningful than the Overall Score!

So, after all the explanations, here are some results (all benchmarks are run on a 15” Retina MacBook Pro 2.6 GHz i7 running OS X 10.10):

The scores have been scaled so that Firefox = 1.0, to fit onto a single chart. Higher is better.

Some observations:

In almost all benchmarks, Firefox with asm.js is faster than both Chrome and Safari in almost all benchmarks, and is currently the best browser to run Unity WebGL content. We hope to see asm.js support showing up in other browsers in the future as well, however – see here for some interesting comments on this subject.

When you are mostly GPU-bound, you can expect WebGL to perform very similar to native code.

In some areas, WebGL will actually outperform native code significantly. This is the case for tests which rely a lot on script performance (Mandelbrot and CryptoHash, which both implement their algorithms in C#), as IL2Cpp can produce more optimized code (expect to read more about this in another blog post soon).

Native code can still be several times faster than WebGL for areas heavily optimized to use multi-threading and/or SIMD, such as the 3D physics tests (PhysX 3.3 in Unity 5.0 is now fully multi-threaded). Compared to that, 2D physics is very close to parity when comparing Firefox to Native (Box2D is not multi-threaded). We hope that the future will bring SIMD and multi-threading extensions to JavaScript, at which point this may change.

The most important takeaway is, while there are still areas where WebGL is significantly slower than native code, overall you can get expect very decent performance already, and this can only get better in the future. I hope that these benchmarks may help anyone looking to optimize performance of their JS engines and WebGL implementations to run Unity content as fast as possible.