Re: Object allocation

[Fred Kiefer]

Adam Fedor wrote:
> On Sat, 2003-11-29 at 07:15, Fred Kiefer wrote:
> > As GNUstep still spends alot of the run time in memory management, these 
> > changes will surely have a noticable effect. I am not that sure about 
> > further optimisation, as using a pool for other classes as well.
>
> Have you done profiles of GNUstep applications to see this? Which
> applications?  I was just wondering if we had looked at some 'real'
> applications like GWorkspace or GNUMail to see where most of the
> time/memory was spent.

Profiling a 'real' applciation is always hard, as what would you call a 
correct pattern for the normal usage? So here are the first few lines 
from a random profile for libgnustep-base of GWorkspace:

Flat profile:

Each sample counts as 0,01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
  9,18      1,47     1,47        0     0,00 
_i_NSRunLoop_OPENSTEP_performSelector_target_argument_order_modes_
  8,68      2,86     1,39        0     0,00 
_i_NSConstantString__hash
  5,31      3,71     0,85   779469     1,09           NSMapGet
  4,93      4,50     0,79        0     0,00 
_i_NSRunLoop_Private__checkPerformers_
  4,56      5,23     0,73        0     0,00 
_i_GSDictionary__objectForKey_
  4,00      5,87     0,64    12125    52,78           GSFormat
  3,62      6,45     0,58        0     0,00 
_i_NSConstantString__isEqual_
  2,75      6,89     0,44   509904     0,86           NSAllocateObject
  2,43      7,28     0,39        0     0,00           _i_NSObject__release
  2,37      7,66     0,38        0     0,00           strCompCsCs
  1,75      7,94     0,28        0     0,00 
_i_NSObject__performSelector_withObject_
  1,69      8,21     0,27        0     0,00           GSeq_normalize
  1,69      8,48     0,27        0     0,00 
_NS_non_retained_id_hash
  1,37      8,70     0,22   509979     0,43           GSDebugAllocationAdd
  1,19      8,89     0,19   268818     0,71           GSDictionaryForThread
  1,19      9,08     0,19   252705     0,75           GSRunLoopForThread
  1,12      9,26     0,18    61570     2,92           GSFromUnicode
  1,06      9,43     0,17        0     0,00           _i_NSObject__dealloc
  1,00      9,59     0,16    94296     1,70           GSToUnicode


There is the hash method (I think the profiler is not acurate in 
assigning methods to classes, but here NSConstantString looks 
plausible), but beside this the runloop methods are rather visible. I 
have to admit that NSMapGet uses even more time than NSAllocateObject 
and therefor should be looked at as well. But this may be harder to 
localize.


And here for the curious the same for libgnustep-gui:
Flat profile:

Each sample counts as 0,01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 10,69      0,48     0,48        0     0,00 
_i_NSWindow_GNUstepPrivate__handleWindowNeedsDisplay_
  4,68      0,69     0,21        0     0,00 
_i_GSHorizontalTypesetter__layoutLineNewParagraph_
  3,79      0,86     0,17        0     0,00 
_i_NSWindow___checkTrackingRectangles_forEvent_
  2,23      0,96     0,10        0     0,00 
_i_GSLayoutManager_glyphs_invalidateGlyphsForCharacterRange_changeInLength_actualCharacterRange_
  2,00      1,05     0,09        0     0,00 
_i_NSLayoutManager__textStorage_edited_range_changeInLength_invalidatedRange_
  1,78      1,13     0,08        0     0,00 
_i_GSLayoutManager_glyphs_helpers__generateGlyphs_char_r______
  1,56      1,20     0,07        0     0,00 
_i_GSLayoutManager_glyphs_helpers__generateGlyphsUpToCharacter_
  1,34      1,26     0,06        0     0,00 
_i_GSLayoutManager___generateGlyphsForRun_at_
  1,34      1,32     0,06        0     0,00 
_i_GSTextStorage__length
  1,34      1,38     0,06        0     0,00 
_i_GSTextStorage__setAttributes_range_
  1,34      1,44     0,06        0     0,00 
_i_NSTextStorage__processEditing
  1,34      1,50     0,06        0     0,00 
_i_NSWindow___checkCursorRectangles_forEvent_

Surprising to see that even though no bigger text was displayed the text 
system still fills most of the top range. For the 
handleWindowNeedsDisplay method it is not clear where the time is spend. 
In the update, which should show in this profile, but doesn't, or in the 
 runloop call.

I undeerstand your reluctance against pre-mature optimization. We have 
to be careful not to waste any development here.

Fred