[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The goal of GNUstep 1.0

From: Richard Frith-Macdonald
Subject: Re: The goal of GNUstep 1.0
Date: Tue, 1 Nov 2005 08:49:01 +0000

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]