Re: NSSound Reimplementation

[David Chisnall]

On 16 Jul 2009, at 14:23, Jamie Ramone wrote:

> I'd like to chime in here and say that this approach IS actually a
> good idea as :
>
> 1 ) it does solve the ABI change breakdown problem and

Except that it doesn't, it just hides it.  Now people subclassing and  
referencing variables in the superclass need to explicitly cast a  
pointer to a structure.  If this structure changes, they need to  
manually update their private copy of the ivars and if they don't  
thing break in exciting ways.

> 2 ) it is actually much easier to read because it's a prime example of
> encapsulation and abstraction, so complexity is hidden.

It is not easier to read, because now you need a separate structure  
definition, every ivar access has to go via a macro which will look  
something like this:

#define ivar (((struct private_ivars*)_private)->ivar)

In no possible way is that clearer code.

> So locality of reference is gone. It gets replaced by messaging an
> object. OK. So what? Why depend on locality? Again, I'm hard pressed
> to find an objective way to choose one over the other. If the API of
> the messaged object is well defined then I find both forms of the code
> to be equally understandable. But that's my opinion, some may agree
> and others disagree. So this reasoning is also a bad one for judging
> the approach.

Clearly you have no idea what locality of reference means.  See here:

http://en.wikipedia.org/wiki/Locality_of_reference

In summary, for good performance you want data that is accessed  
together to be close together in memory.  Both CPUs (via their cache  
architecture) and operating systems (via their paging strategy)  
optimise heavily for this case.

Having ivars dangled off on a separate structure means that we now  
need two cache lines per object instead of one.  Actually, it's worse  
if you also factor in subclasses doing this because you need one cache  
line for the object and one for each of the subclass structures.  This  
will increase cache churn considerably.  This is very difficult to  
identify in a microbenchmark, but it affect performance in larger  
programs quite noticeably.  These structures, being separately  
allocated and of different sizes, may well be on different pages  
meaning that you will end up with a lot of more swapping when you are  
low on memory, which completely cripples performance.

The correct solution is to declare no ivars other than ones you are  
willing to commit to maintaining in the future in the header, declare  
them all in the implementation file, and use non-fragile ivar support  
in the runtime, but this requires people to actually test my patch  
which adds this.

At the very least, we should just add an unused pointer for future  
expansion so that we can add new ivars later and not use this for  
ivars that are likely to remain stable for several releases.

David