|
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. Theother side is that we could use more bit fields to make these classesmore compact. After a 1.0 release it will get pretty hard to change thememory usage of these classes, so we need to do it now.I'm curious, if you have some measurements to show that using bit fieldsis a good idea. I have the feeling that -gui does not really createenough instances for the compactness of these instances to outweigh theperformance hit due to the fact that the compiler actually has togenerate more code for accessing bit fields than more naturally alignedivars.
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.
[Prev in Thread] | Current Thread | [Next in Thread] |