Re: The goal of GNUstep 1.0

[Richard Frith-Macdonald]

On 30 Oct 2005, at 16:13, David Ayers wrote:



> Fred Kiefer schrieb:
>
>
>
> > On the more down to the bits side, I would like to see a stable  
> > memory
> > layout for all GUI classes. This has two aspects, we are still  
> > missing
> > some ivars that will be needed for full OpenStep/Cocoa compliance.  
> > The
> > other side is that we could use more bit fields to make these classes
> > more compact. After a 1.0 release it will get pretty hard to  
> > change the
> > memory usage of these classes, so we need to do it now.
>
> I'm curious, if you have some measurements to show that using bit  
> fields
> is a good idea.  I have the feeling that -gui does not really create
> enough instances for the compactness of these instances to outweigh  
> the
> performance hit due to the fact that the compiler actually has to
> generate more code for accessing bit fields than more naturally  
> aligned
> ivars.

I agree that using bitfields may not generally be a good idea, but a  
stable memory layout certainly is.

For many classes, Apple hide the instance variables pretty much  
entirely, thus allowing instance variable layout to be changed from  
release to release without break,ing binary compatibility.  I think  
we should consider adopting the same approach.

So, we would only have a limited set of instance variables declared  
(basically those that we want subclasses to be able to access  
directly), and have all others hidden.

a. This can be done by overriding allocWithZone: to call  
NSAllocateObject() with a non-zero argument for extra space, and  
storing the hidden instance variables in the extra space.  The  
disadvantage of this is that it makes it difficult/impossible for  
subclasses to use the same trick of overriding allocation, since they  
don't know how much extra memory to allocate for the superclass  
hidden ivars.

b. Another possibility is to have a single pointer ivar that we can  
use to point to a separately allocated chunk of memory containing  
hidden ivars.The disadvantage of this approach is that each  
allocation/deallocation requires an extra malloc/free for this  
additional memory ... that would be a major performance overhead on  
frequently created/destroyed objects (like cells), but is a  
negligible issue for big, infrequently allocated objects like windows.

c. The third possiblity is to have a load of dummy ivars, and expand  
into the space occupied by them ... wastes a bit of memory and is  
less flexible (what if we want to expand the class in a way the dummy  
ivaars don't allow room for).

d. You can also store the extra variables in an NSMapTable keyed on  
the instance ... but that's really an inefficient variant of option b.

I guess we should use a combination of the first three mechanisms (I  
think Apple do), trying to pick the best scheme for each class.