Re: The goal of GNUstep 1.0

[Fred Kiefer]

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've hacked into -base's Testing/benchmark a little test to show the
> difference.  (Note I'm not planing to commit this, it was just a
> convenient place to put it.)

Thank you for the nice test code. On my i586 machine this gives a 5%
slowdown for a 1/3 memory reduction. Other machines may give totally
different results. But as Richard already pointed out, bitfields or not
isn't the big question, it is more important to have a stable memory
layout for the GUI classes.

On the other hand there are a few classes where hundreds if not
thousands of instances are rather common, NSCell (and its subclasses)
being the most prominent example, NSEvent a not so prominent one. We
don't need to go as far as Apple did with bitfields, but we should at
least go through all the classes in GUI and have another look at the
memory layout: Could it be improvied by reordering ivars? Do we need
space to grow for this class? Are we missing ivars needed for full
Openstep or Cocoa compatibility? Should we use bit fields?

Fred