[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The goal of GNUstep 1.0
Re: The goal of GNUstep 1.0
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
layout for all GUI classes. This has two aspects, we are still
some ivars that will be needed for full OpenStep/Cocoa compliance.
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
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
is a good idea. I have the feeling that -gui does not really create
enough instances for the compactness of these instances to outweigh
performance hit due to the fact that the compiler actually has to
generate more code for accessing bit fields than more naturally
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
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.
- Re: The goal of GNUstep 1.0,
Richard Frith-Macdonald <=