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