Performance of GNUstep applications

[Fred Kiefer]

Now that the performance of GNUstep applications once again becomes a 
discussed issue, it seems like a perfect time to me to publish the 
measurements I did. But I don't have the sligthest idea what conclusions 
to draw from them.
As Nicola wrote some months ago, it is fairly easy to profile a GNUstep 
application on a system that supports dynamic loading of libraries. 
GLIBC has build in support for profiling, all you have to do is to put 
the library you want to profile into the environment variable 
LD_PROFILE. In my bash this gets done for the base library via:

export LD_PROFILE=libgnustep-base.so.1

Than run your application as usual and use sprof to view the result:

sprof libgnustep-base.so.1 /var/tmp/libgnustep-base.so.1.profile

For my test application (GSTest.app), this resulted in the following:
Flat profile:

Each sample counts as 0,01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 13,67      0,35     0,35        0     0,00 
_i_NSConstantString__hash
  4,30      0,46     0,11   143392     0,77           NSAllocateObject
  4,30      0,57     0,11        0     0,00           GSeq_normalize
  4,30      0,68     0,11        0     0,00           _i_NSObject__retain
  3,12      0,76     0,08   405044     0,20           uni_is_decomp
  3,12      0,84     0,08        0     0,00 
_i_GSDictionary__objectForKey_
  2,73      0,91     0,07   191287     0,37           GSCurrentThread
  2,34      0,97     0,06   409699     0,15 
NSDecrementExtraRefCountWasZero
  2,34      1,03     0,06   209596     0,29           uni_isnonsp
  2,34      1,09     0,06        0     0,00           _i_NSObject__release
  2,34      1,15     0,06        0     0,00           default_malloc
...

It is surprising how much of this is string manipulation, although 
GSTest.app doesn't use this much. And I really dont understand why 
_i_NSConstantString__hash leads the list, as the string code tries to 
make sure that this never gets called. It may be that objects of class 
NSConstantString make it into NSDictionary often, where [hash] is used alot.

Doing the same things while profiling gui (export 
LD_PROFILE=libgnustep-gui.so.0) results in:

Flat profile:

Each sample counts as 0,01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 17,11      0,13     0,13        0     0,00 
_i_NSView__displayIfNeededInRectIgnoringOpacity_
  6,58      0,18     0,05        0     0,00 
_i_NSView__unlockFocusNeedsFlush_
  3,95      0,21     0,03        0     0,00 
_i_NSAffineTransform_GNUstep_pointInMatrixSpace_
  3,95      0,24     0,03        0     0,00 
_i_NSView__convertRect_toView_
  3,95      0,27     0,03        0     0,00 
_i_NSView__lockFocusInRect_
  3,95      0,30     0,03        0     0,00           setupRun
  2,63      0,32     0,02     2595     7,71           NSDrawTiledRects
  2,63      0,34     0,02     1239    16,14           NSRectClip
  2,63      0,36     0,02        0     0,00 
_i_NSColorWell__drawRect_
  2,63      0,38     0,02        0     0,00           _i_NSMenu__update
  2,63      0,40     0,02        0     0,00 
_i_NSView___matrixFromWindow
  2,63      0,42     0,02        0     0,00 
_i_NSView___rebuildCoordinates
  2,63      0,44     0,02        0     0,00 
_i_NSWindow___checkCursorRectangles_forEvent_
...

This also tells not that much about where we waste time. The drawing 
itself and most of the code in the lock/unlock methods has to do real 
tasks. But why does NSColorWell showup at all?

I still haven't found out how to profile the back library although this 
should be the place where most of the time gets lost. Putting the 
directory where this file is located into the LD_LIBRARY_PATH is not enough.

Another interessting thing to notice is how many objects of each class 
get generate during the livetime of a GNUstep application. Nicolas 
memory panel allows to view this for all applications with an info 
panel. In the cases I tested the three classes 
GSDictionaryKeyEnumerator, NSAffineTransform and XGGState make up for 
the biggest part. As two NSAffineTransform objects are owned by each 
XGGState most of the NSAffineTransform objects come directly from the 
XGGState. Managing the creation of objects for only the remaining two 
classes differently would dramatically reduce the amount of created objects.

Hopefully this will be the start of more reasearch into where our code 
spends its time.

Cheers
Fred