SetParent causes much Overhead in profiler even when not called

Unity Engine
1

Hi, I’m using Unity 5.3.6f1 and I’m working on a target tracking head-up-display with pooled UI widgets. The pooling code is set up to look for a free (deactivated) widget when a new one is needed, and if one isn’t found, to instantiate one (including setting the parent, a canvas, with SetParent).

In my test case the number of targets does not change so as soon as the pool is big enough nothing new is created, which means SetParent is not called (I’ve checked this too with Debug.Log). However it seems that simply having the possibility of a SetParent call causes a huge and continuous Overhead in the profiler of around 4-5ms.

If I comment out the SetParent() line the Overhead goes down to around 0.5ms, but what bothers me is that it is not called anyway except at the beginning. It seems very strange then that the performance impact in the profiler is continuous, and 5ms is nothing to sneeze at, especially on mobile.

Is this some kind of bug or expected behaviour? Thank you for any insight.

PS It seems to be the case only with a world space canvas as the potential parent. If I switch the canvas to Screen Space Overlay it goes back to 0.1-0.5ms

2

What is your build platform?
are you profiling in editor mode?
Plus can you share your code.

3

Thanks for reply, I’m profiling in editor mode, build platform is webplayer (I know, but I need it still).

The code is part of a bigger whole, so it’s kind of hard to pull it out, but let me put it this way: I put a Debug.Log(“hello”) just before the SetParent call, and after the game started, except for during Start(), the Console showed no calls - as expected. However the Overhead was showing 5ms lag continuously. Then I commented out just the SetParent line, ran the game again and the Overhead disappeared. Also, simply setting the canvas to Screen Space also killed the Overhead.

I decided to transfer the HUD out of the UI (to SpriteRenderers and LineRenderers) anyway since uGUI seems to suffer with a bunch of stuff such as when resizing the sizeDelta of the an image RectTransform during play. I’m convinced that it’s not designed for a dynamic HUD but rather for menus and that sort of thing.

The only thing I could find on the topic was this thread, which suggests that 5.3 had some issues with SetParent that were only fixed in 5.4.

4

Well if this is an established bug in v5.3 then you should update Unity.

5

Unity doesn’t do any magic stuff to premtively see if you might call a function. You will only see the cost of SetParent if you actually call it.

Which leads to the conclusion that despite your insistence, you actually are still calling the function. Perhaps from somewhere else?

6

OK now that I’ve got some sleep it occurs to me that without having parented the UI objects, they wouldn’t be rendering on the canvas, and the overhead is probably just the overhead of doing stuff on the canvas.

It was masked by the fact that I’d attached some non-UI sprite elements to the UI prefab to test alternatives, and that made me think it was still rendering properly.

Thanks very much for replies.

If anyone is interested though, non-UI elements such as the SpriteRenderer and LineRenderer appear to be significantly faster for world-space stuff than using Image objects on a world-space canvas, especially when it involves resizing and setting transforms on a per-frame basis. At least in 5.3.6.

7

So whats the alternative to Selectable components. I mean how would you handle UI events like click, drag, pointer down etc?

8

It’s for a 3D radar, so no buttons or events, just a lot of sprites flying around. The new UI just seemed like the obvious choice but it seems like it’s mainly good for interactive stuff.