Benchmarking Unity performance in WebGL
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.
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.
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).
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.