Performance differences in UnityGUI versus GuiText/Texture?

I've seen occasional talk about the performance of various GUI features, and how to improve them. But I haven't found a comparison of the performance between UnityGUI, the all-in-one GUI interface (what OnGUI() does), versus the roll-your-own GUI Text/GUI Texture.

So how do they compare? How much does it cost in speed to use UnityGUI/OnGUI()? Assuming reasonably well-designed code, but with a good number of buttons, textfields, etc.

Personally, I would have thought that Unity would do plenty of optimization on UnityGUI. However, I ran across this, while searching for GUI posts: "OnGUI was not designed to be something that you'd actually ship with a product. It's only there so that you can create UI quickly for debugging purposes, or just for placeholders. For a real, shippable UI, you need to roll your own, probably using GuiTexture and GuiText."

Is he right? What is the intended purpose of UnityGUI? Certainly the main Unity manual pages seem to feature it, with not a word about performance issues. Nor does the Optimization section suggest otherwise.

The comment about "not designed to actually ship with a product" is bizarre. I would ignore it. That said, OnGUI is typically lower-performance. For one thing, it's recalculated at least twice per frame (immediate mode), whereas GUIElements are just set once (or whenever you change them) and have no cost aside from the usual cost of having objects in the scene (such as draw calls). In particular, using GUILayout in OnGUI has even more of a performance penalty because of having to calculate Rects instead of having them supplied. The Unity iPhone docs do suggest not using OnGUI in-game, but only for menu levels.

The benefit of OnGUI is being able to create complex GUI systems relatively easily, and having a much larger set of built-in GUI tools to work with, such as sliders, scrollbars, text fields, etc. The more complex your GUI gets, the more painful GUIElements are to work with.

Both systems have advantages and drawbacks. I use GUIElements for simple items like typical score readouts, health bars, etc., especially since GUIElements are trivial to make resolution-independent, whereas this is possible but annoying with OnGUI. With more complex (and more typically non-game) GUI systems, I use OnGUI.

In the context of iPhone, here is some data:

Just plopped some of my UnityGui code from a web project into the Unity iPhone trial and got some numbers. It is a dialog a bit smaller than the size of the screen, with three medium buttons sitting in the middle. Note the number of draw calls are inflated by 2 because of the "unity trial" texture that they put in the corner.

`iPhone Unity internal profiler stats:
cpu-player>    min: 12.3   max: 22.9   avg: 16.2
cpu-ogles-drv> min:  1.1   max:  4.1   avg:  1.4
cpu-present>   min:  1.1   max:  4.4   avg:  1.4
frametime>     min: 30.1   max: 37.9   avg: 33.7
draw-call #>   min:  10    max:  10    avg:  10     | batched:     0
tris #>        min:   202  max:   202  avg:   202   | batched:     0
verts #>       min:   304  max:   304  avg:   304   | batched:     0
player-detail> physx:  1.2 animation:  0.0 culling  0.3 skinning:  0.0 batching:  0.0 render: 13.3 

fixed-update-count: 1 .. 2 mono-scripts> update: 0.1 fixedUpdate: 0.0 coroutines: 0.3 mono-memory> used heap: 262144 allocated heap: 356352 max number of collections: 0 collection total duration: 0.0

`

And here is my analysis:

10 draw calls for a window with three buttons is perhaps a bit much if you want to show anything else while on iPhone.

There is a thing called GUIManager on the forums somewhere that is supposedly optimized for iPhone and will draw your whole GUI in one draw call.