The Performance Questions Thread

I have not seen a thread dedicated to performance questions and best practices, so here it is. If there is one, please point me to it and/or merge the questions below.

We are very pleased with the workflow and functionality of the GUI system, but how it performs under different circumstances and why is something I have yet to grasp. I would be very thankful if the Unity team would like to adress the questions below.

• We use multiple canvases for a very complex UI. In the editor we notice canvas-related performance problems. Ie. if we disable the canvases we notice a big performance boost. However, not so much (if at all) in a standalone build. Why is this, and is it intended behaviour for final release (or beta related)?
  While it is always hit and miss to profile in the editor, the current state of GUI performance makes it impossible.
• Are elements on a canvas "cached"? Ie. is each individual element rendered each frame, or is the canvas contents composited when an element changes and then "batched" during subsequent, non-changing frames?
• Are there circumstances that should be avoided for best performance? For example, using world space canvases, is there a performance penalty if you position canvas elements in z space?
• Does a canvas itself incur a performance penalty even though the majority of it is not populated. For example, consider a large canvas that only contains a small visible element. Is the cost of the canvas hierarchy related to the canvas size or the element size?

I am sure others can add to the questions. Many thanks in advance for any info from the team! I am sure many devs would find the info very useful.

 

BUMP. Please...?
Either this info is already out there, or it needs to be?

 

I also have one question - let's assume app has 20 screens. Is it better to have each of the screen in it's separate canvas or all of the screens in the single canvas? I early betas (like b7 or b9) we went with only canvas but then it seemed that even inactive objects got sorted therefore the performance was terrible (hence we switched to multiple canvases). Wonder what is the best practice for this?

 

Thanks for your reply!
Disabling a canvas does have impact on standalone, only much, much less so then in the editor. My current experience is that there seems to be an overhead when running the new UI in the editor as opposed to when built.

I am still hunting for the exact cause, but while doing so I noticed that batching seems to be broken. To verify I created an empty scene with a couple of standard cubes. They did not batch. Is batching turned off in 4.6b? Perhaps better to start a thread about that...

 

I also started the thread with regards to performance: http://forum.unity3d.com/threads/performance-on-color-lerping.275609/

I think we have the same problem on the "editor-only-performance" part.

Pixel perfect didn't solve my issue for 2 reasons.
- I'm using a world space canvas (no setting for pixel perfect)
- Problem isn't with the canvas hierarchy since performance is fine if I disable my custom script which lerps the color (see my thread for details). Also, it's perfectly fine when built.

 

The situation is not exactly the same, but the root cause might be. In my case we have a rig with:
- Several world space canvases
- Poor performance in editor as soon as they are in camera view, even without any scripts updating the contents
- When built there is still a performance difference, but this is relatively minor (from 180fps->160/170fps) whereas in the editor I see a drop from 60fps solid to around 20fps. So there seems to be a lot of overhead in the editor, more so for the GUI than other things.

 

I am now quite sure this is due to the editor itself and quite possibly a bug (or debug stuff still left in). Take a look at the enclosed picture. It shows the *editor* profiling when running the scene with the strange GUI behaviour.
When the GUI stuff is not present in view, the fps is synced to 60fps. As soon as the GUI stuff enters the frame, according to the profiler the *editor* uses practically all available resources. As mentioned earlier, I can confirm this is likely an editor issue as the built scene will not exhibit this behaviour.
I can not submit this project due to it's current state in development, but I urge the dev team to take a look at situations with several world canvases and in-editor behaviour (at least on Mac OSX with b21).
The problem is intermittent and when in effect makes development a pain in the proverbial.

 

I should add that as far as I can tell, the performance is mostly affected by canvases being visible in the editor view. I have two monitors with the second being dedicated to game view and the primary is editor view. Having the editor view containing the canvases will often trigger the behaviour. As previously noted, the is intermittent, happening about 80% of the time.

 

I found the cause in my case.
Unbelievably, this only happens when running Unity with The scene and game view on different monitors. Collecting the views on one monitor makes the framerate shoot up to 100-200fps, and there is NO difference in framerate whether I have active canvases or not. Whereas with the views on two different monitors, active canvases can cause the FPS to drop from 60-70fps to 10.
Is there a known case of Unity performing poorly with views on different monitors? Will have to search for that.
Regardless, this difference in performance is quite disappointing as it is very convenient to use separate monitors for the game and scene views...

 

We've been getting GC spikes when we turn uGUI components on and off.

http://forum.unity3d.com/threads/lots-of-allocations-in-canvasrenderer.277314/

 

I would like to report this complete with a repro. However, I cannot easily reproduce it in a new project as it seems the combination of substances, GUI and a fair bit of geometry pushes Unity into a situation where the editor does *something* that impacts performance severely if either of the game/scene windows are on an external monitor.
I cannot simply submit the scene that exhibits the problem as that would require you signing an NDA (which I understand you will not do).

For what it is worth, the scene is using substances, mechanim, the new UI (with several world space canvases) and is running under Mac OS 10.9.4 with Unity b21. New Mac Pro 8x3ghz Xeon E5 and dual D700 cards, dual Apple Thunderbolt displays.
With the windows separated on the external screen Unity seems to cap at 60fps (even with vsync and target framerate off) and often drop to around 10fps with the GUI system in play. With the windows on the main display, frame rate seems uncapped and unaffected by the presence of the GUI (fps in the 150 - very high range).

Please let me know if I can provide more info, or if there is something in particular you would like us to test. I am sorry we simply cannot submit the project, we are not able to do so.

 

Currently, I have a world space canvas (reserved for the whole game) ready where I can put the number objects. I'll try having each object have its own canvas then since all of them are dynamic.

Another question, is this an editor-only problem? Or does it apply to built project, just that built projects run faster than from editor?

 

I've tried separating each object on its own canvas. Later, these objects will be nested under a bigger canvas. I still get almost the same slow performance while running it in the editor. Also the same with built projects, it runs smoothly.


EDIT: I just upgraded to RC1. It's fixed now. I guess it was editor-only before XD