NSCell vs NSView: when many controls are needed

Question

I am aware that Apple is deprecating the use of NSCell in favour of NSView (see AppKit 10.10 release notes). It was previously recommended that NSCell be used for performance reasons when many controls were needed.

I have spent considerable time implementing a custom control that required many subViews and the performance using NSView-type subViews was not good. See related stackoverflow discussion What are the practical limits in terms of number of NSView-type instances you can have in a window? I was struggling with 1000-2000 in-memory objects (which doesn't seem a lot). What is the actual reason for this limitation?

One thing that confuses me on the above is View-based Cocoa NSTableViews. You can create tableViews with more than 1000-2000 cells and they don't seem to have poor loading and scrolling performance? If each of the cells is an NSView then how is this achieved?

If there are practical limits, then what are Apple thinking when they say they are deprecating usage of NSCell's? I am sure they are aware that some controls need a large number of subViews.

Further, an (probably outdated) Apple Developer Guide give the following explanation for the difference between NSView & NSCell which I need explained further:

"Because cells are lighter-weight than controls, in terms of inherited data and behavior, it is more efficient to use a multi-cell control rather than multiple controls."

Inherited data: this would surely only cause "bloat" if the data was being used => and it would only be used it you needed it?

Inherited behavior: methods that you don't use in a class/object surely can't cause any overhead ?

What is the real difference between the lightweight NSCell versus the heavyweight NSView other than that it just seems to be conventionally accepted? (I would really like to know.)

Intertwine

The "lightness" of NSCell has to do with a lot of their drawing being optimized for reuse, not the size of the instance. – Heeley

@Heeley How is their drawing optimised for reuse? Each one has its own "draw" method analogous to NSView's drawRect. – Intertwine

Don't worry too much. there's still a lot of code that will break if the kill NSCell. It's only been verbally informally deprecated. NSTableView tries to recycle views in a reuse pool. drawing was once the providence of machines that were less powerful than the iPhone (Next cube) and that's just not the case any more. – Wainscoting

@Wainscoting I hear you on the NSCell deprecation. If machines are so powerful now then why is my computer struggling with 1000-2000 NSView subViews? Is it an indication that the approach of using NSViews is fine but that I am doing something wrong? – Intertwine

Probably. That would be a large number of views at once. Especially if they draw or layout frequently. One part though could easily be the drawing code. But there could be any number of areas to optimize with that many views. – Wainscoting

Answer 1

A brief and incomplete answer:

NSCells are about drawing state, and not much else. NSViews must draw, but also must maintain and update all kinds of other information, such as their layout, responding to user input events, etc.

Consider the amount of calculation that must happen if you resize a view that contains many hundreds of subviews: every single subview position and size must be maintained according to the existing constraints for the view layout. That alone is quickly a very large amount of processing.

NSCells, in contrast, don't exist in a layout in that way. Their only job is to draw information in a given rectangle whenever asked to do so.

Hoopla

I run into the same problem and the way i see it that Apple isn't caring anymore about high density information display with tousands of views. It's all optimized for low density web like looking mobile apps now. NSCell is not dead. Even 6 years later. – Frore

Answer 2

One thing that confuses me on the above is View-based Cocoa NSTableViews. You can create tableViews with more than 1000-2000 cells and they don't seem to have poor loading and scrolling performance? If each of the cells is an NSView then how is this achieved?

NSTableViews re-use views. The only views actually generated are those that are visible, plus maybe a row of views above and a row below the visible area. When scrolling the table, the object value associated with a given row of views is changed to that the views in the row will display different content

Refinery