Unity profiler, just another rant.

Unity Engine
1

I got to vent it.!
Today I had to restart my cpu once again because of unity3d profiler ravenously eating all my resources/“cpu time”. Naturally clicking on pause button or profiler stop button did nothing, even when I have started doing it when it was still few fps above 1. Even ctr+alt+del was a problem and Task manager was unusable.

Is it so difficult to put UI on different thread ?
So at least we could know that we have pressed the damn button.

Or just add the possible condition to auto-stop profiling when your fps goes below 1fps for a while.

Now this Bug as I’m calling it, is probably a decade old. Ain’t it speaking by itself ?

1 Like
2

Hi

We are working on multiple fronts regarding the stability and performance of the Profiler. We’ve recently landed multiple fixes (for out of memory crashes) and performance improvements, in particular for Timeline view. Most of which are on the latest versions of 2019.3, 2020.1 and 2020.2 or are about to be released with the next version.

Yes. Currently all Unity UI code, whether that is IMGUI, uGUI or UIElements is Main thread bound, in the Editor and in the Player. Playmode runs in the same Main thread as the Editor, which allows for all the comforts of seamless interaction between the Editor and Playmode, but comes with the downside of these two modes affecting each other’s performance and memory usage. This is an architectural problem and not easy to resolve, but that too is being worked on at multiple fronts. One of these is Live Link, as shown at Unite Copenhagen 2019.

Another approach to this is the Standalone Profiler which was added as an Experimental feature in 2020.1. This feature will spin up a minimal Editor process that contains the Profiler tools. With this, you can profile the Editor or Playmode without the Profilers being in the same process and directly influencing what they profile. They still do so indirectly, because they share the same system and resources, but it aleviates some of the problems in this and provides cleaner profiling results. This extra process currently takes some 30 seconds to launch, which we want to reduce but this too shows that this is not a trivial problem to solve.

Another recent addition that highlights some of the issues is the addition of a “Live” toggle to not update the CPU/GPU details views while recording Playmode or the Editor by default, because that would impact the very thing being profiled or even lead to recursive Profiling of the profiler UI itself (when Editor profiling). You can simulate the same behavior in versions without this toggle by selecting a different module while recording.

We obviously want the Profiler to be as performant and useful as it can be in any context, including Editor and Playmode profiling, but the cleanest data is still going to come from profiling a different device.

I guess, all this to say: we are not just sitting on this, as well as that the issue (in some form or another) having existed for a while is in part down to structural problems that need resolving (which takes a while).

Now, with all that out of the way, I’d like to dive in a bit more into your specific issue: What Unity version are you using? What Profiler Modules were open? What were you profiling? The Editor or Playmode?
Normally the Profiler Window should only Repaint about every 5th frame of the Editor/Playmode. This should technical preclude the cost of repainting the window from stacking up frame over frame. It sounds like it might not be doing that in your case and it’d be good to know why that might’ve been. Or if this was down to something else entirely.

Lastly, we can try to troubleshoot this here but we also always welcome these kind of issues as bug reports. And just because it seems like an obvious bug and the same one over time, doesn’t mean it is, so any report that is as specific as possible in how the performance of the profiler falls short can help us uncover other issues, combinations of issues or validate existing pains.

3 Likes
3

I was doing Playmode deep profiling. Unity3d 2019.3.12f default modules open.

The main problem as I see it is with the registration of mouse clicks.
I already got few times this situation when pressing the stop button did nothing, so I pressed again and than both clicks are registered and it just pauses and resumes.

Also I got this impression that when fps goes down I had to press and hold a mouse button for a while before releasing it for a mouseclick to register.

Anyway thank you for such a long post I just hope you will manage to finally find some solution to this problem.

Best Regards.

4

Since at least the alpha of 2019.3 (if not already earlier, including 2018.4? can’t remember 100% right now), the Profiler remembers the last state of which modules where used on a particular machine so there if you already closed some of these, it wouldn’t have opened them by default. As such, there isn’t really a default set unless you never changed that on your PC.

If indeed all modules where open, it could be that one of these forced a repaint every frame. I think the UI profilers did that for a while (could be fixed). Also maybe the Audio profiler added some profiling overhead? Anyways, closing any modules you don’t need means you’re no longer inuring the performance cost of collecting the data they use so this can be a way to A) find modules that have too big of a performance impact (and potentially report that as an issue) and B) to reduce the overhead and have the profiler be as lean and the data as clean as possible.

This version should already have had most of the Timeline performance improvements except for the Live toggle which will be release with version 2019.3.14.

So, in case this happens again, it would be good too know more details to see if there’s an issue we overlooked with these, like the added modules, the currently active one as well as the view it was showing (Hierarchy/Timeline, Simple/Detailed …).

Also, in 2019.3 we added the ability to have the profiler retain 300-2000 frames so it’d also be good to know what that setting was set to and if it is maybe down to too many frames being held in memory.

I think This might be a general Editor issue. I’m not sure if this is still happening with UIElements UI (Profiler window is sadly still using IMGUI) but to register a button click, it’s my understanding that the editor UI might need 2 frames. One with the Mouse button pressed, and one with it released. I think the same might not apply to key presses like shortcuts.

Thankfully, since 2019.3 there’s a shortcut for enabling/disabling recording of the profiler. The default shortcut is F9 but you can change that in the shortcut manager. So try pressing that key the next time this happens. Oh and, the Profiler Window doesn’t need to be open to use this shortcut, so you can forgo the Profiler Window overhead entirely.

So, we’ll keep looking for things to improve and optimize, both workflow and performance wise. But please do let me know/ report bugs if there is anything we seem to have missed.

1 Like