Performance of UIView: removeFromSuperview VS hide

Question

This question is really basic. What is the performance difference between removing a UIView from the view hierarchy and hiding a UIView?

I have read that Views that are not needed should be removed from the view hierarchy. I currently have the situation that a UIButton should sometimes be visible. When do I hide the UIButton and when do I remove it from it's superview?

Is it expensive to change the view hierarchy?

Coralyn

Answer 1

If you need to alternate between showing and hiding the subview, the best approach is definitely hiding it. For a UIButton the memory implications are not that great anyway. And the code is certainly simpler if you just switch the hidden property.

Also, you get the additional advantage that the hidden property is animatable!

Appoint

So what is the difference between rendering a hidden UIView and not having that view in the view hierarchy? Is there a difference? – Coralyn

Yes. In case it has been removed, you are basically recreating it from scratch. This could be good for memory management, but it could be bad for performance, and less pretty as you cannot animate the change. – Appoint

Well if you keep a reference to the view it does not have to be recreated. I was interested in the overhead of altering the view hierarchy. What does this alteration trigger. I imagine that it basically alters a tree structure that UIKit is managing as a representation of the view hierarchy. Do you think that's accurate? – Coralyn

Correct what you say about the reference. I think the hidden method is more efficient, exactly for the reasons you state. But you would have to create a pretty hefty testing scenario to make this difference felt. (E.g. with lots of table view cells scrolling very fast...) – Appoint

Answer 2

I've done an experiment on iOS6 iPad mini, with a large scroll view that has a lot of rich content (including images, drop shadows, gradient layers, patterned background images, you know, those designers:) ) and I found that view.hidden=YES ≠ [view removeFromSuperview].

I originally thought that setting hidden to YES will make the view not being render/drawn, therefore having a lot of hidden views will have no impact on efficiency. But the actual result is: 1) if I set the offscreen views in the big scroll view to hidden (and unhide them when they come back into visible area), the scrolling is not smooth/continuous at all. When it's naturally decelerating it looks very jumpy. 2) if I remove the offscreen views from the scroll view (but still keep in memory with a tracking array, so when they come back in they can be added immediately), the scrolling is obviously smoother.

Simple

That actually to me reiterates the fact that setting a UIView to 'hidden' saves it from being rendered and possibly increases performance in some way. Sure, the jumpiness is from making it 'unhidden' which possibly forces a setNeedsDisplay along with a setNeedsLayout (not sure about the latter), which would contribute to the slow down. For a tableview it's possibly a bad idea, but for a much larger view 'behind' other views, it may be a good idea to hide it so that it doesn't trigger a redraw needlessly when not needed. – Unfailing

"2) if I remove the offscreen views from the scroll view (but still keep in memory with a tracking array, so when they come back in they can be added immediately), the scrolling is obviously smoother. " Can you give a short example of this? Sounds like a good way (memory- and performance-wise) to handle off-screen views. – Ammeter

Answer 3

Some years have passed between the initial question and the (rightfully) accepted answer. Let me add another factor: In the meantime, Apple has introduced AutoLayout, which — as some say — might come with quite a performance penalty in certain (deep) subview hierarchies.

If you are using AutoLayout, a view that is hidden will still get layouted, as opposed to the removed view (with its reference saved somewhere). Depending on your scenario, this could then make a performance difference.

Samson