[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Object allocation
From: |
Fred Kiefer |
Subject: |
Re: Object allocation |
Date: |
Sat, 29 Nov 2003 18:59:00 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 |
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