Re: Object allocation

[David Ayers]

Fred Kiefer wrote:

> 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),

Ouch! I ran into a bug due to an optimization done in externs.m and we 
were wondering whether this form of optimization was really worth 
while.  (Using dynamically allocated strings which can cache their hash 
values in place of NSConstantStrings which recalculate them as the 
compiler doesn't  allocate memory to store the hash value.)  Maybe we 
really should use that technique more often (or even consistently for 
exported strings).  We were considering a sarray to store the hash 
values but I'm reluctant, that we may then loose the time in the lookup 
of hash values.  (-base itself my not have that many constant strings 
but if you take -base, -gdl2 and -gsweb, they do accumulate.)

While it still may be papering up other issues, as Adam has pointed out, 
these numbers really look like it would be worthwhile.  But if we start 
doing that, please insure that the strings are first initialized as true 
constant strings and later replaced (so that they will have valid values 
in +initialize methods).

Cheers,
David