LUUG August 2013 – Diagnosing Performance Problems in Unity3D

I gave a talk at LUUG yesterday evening to a reasonably packed room at the Google UK office. The focus was how to go about making games in Unity3D that are performant – that run fast, smooth, and responsively. Specifically I focused on how to use the provided tools to find performance problems, as knowing how to find the bottlenecks is arguably more important than knowing a hodgepodge of situation-specific tricks and shortcuts.

Sadly nobody was on hand to video my flamboyant gestures and silly voices, but here are the Keynote slides and here’s a PowerPoint version. Enjoy!

Category: Uncategorized 5 comments »

5 Responses to “LUUG August 2013 – Diagnosing Performance Problems in Unity3D”

  1. Playlectric

    Hi Richard, great talk last night and thanks for making the slides available online.

    Hypothetically speaking, what is the ideal ratio for the Main thread, the Render thread and the GPU if you want your game to run as efficiently as possible, i.e. with the least amount of delay going from the main thread to the render thread to the GPU with virtually no queuing? Is it simply a 1/3 share (in milliseconds) for each?

  2. Richard Fine

    Glad you found it useful. :)

    A 1/3rd ratio across all three processes (main thread, render thread, GPU) is a reasonable starting point; you’ve got a finite amount of work to do in a frame and in theory distributing the work evenly across all available processors will get it done in the shortest time.

    There are a couple of other factors to consider:

    * Power consumption. If the GPU takes less than 16.6ms to render one of your 60Hz frames, then it’s just going to sit around doing nothing for the remaining time, which means you could use that time to render high-polygon stuff or more complex shaders or what have you – but sitting doing nothing is quite power-efficient. So you should bear that in mind on platforms where power consumption is an issue – particularly mobile.

    * Other threads. What we really try to avoid in multithreaded scenarios is points where a CPU core isn’t doing useful work for us; when the main or renderer threads are having to wait, the CPU isn’t processing them, but it *could* process other useful things for us instead (such as audio, or other threads that we ourselves have spun off from game code). So a little bit of slack time on your main or renderer threads might not actually be as bad as it seems if other threads can use the time to do things.

  3. Playlectric

    Hi Richard, those are very valid points re: power consumption and multi-threaded applications.

    This stuff is actually so fundamental that it ought to be one of the first things Unity developers should be taught.

    However, as you mentioned during your talk, there’s a tendency to focus on frame rates, triangle counts, texture sizes and drawcalls on the Unity forum, and while that sort of approach is often relevant for mobile games/applications, it can be downright misleading if people don’t know how the relationship between the Main thread tasks, the Render thread tasks and the GPU really work.

    Your presentation completely de-mystified this aspect, and if this information isn’t already available in the documentation section of the Unity website, it really ought to be!

    Anyway, thanks again and keep up the good work! :)

  4. a

    1. Webserver’s not configured to send .key as a proper mimetype :(.
    2. Your version of keynote is “too new”; any chance you can export as PDF (neatly circumvents Apple’s forced upgrades :))

  5. a

    …actually, if you manually open in Preview, all is fine. Just Apple being annoying/greedy :(.


Leave a Reply



Back to top