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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
