Michael was sitting in my living room this evening and we were discussion performance issues and I was musing about adding an instrumentation printf to the Squeak VM to grab the method name on each execution of a message send. That way we *know* what messages are being sent in which order. So I decided to code up a test macintosh carbon VM that is found at hftp://ftp.smalltalkconsulting.com/ experimental/SqueakMethodTrace3.8.9b7.app.zip which dumps data to 'messageTraceFile.txt'
One of the things I saw a lot of when opening an image, which generates 40MB of data, is this sequence.
Process context Increment GC count method 107493580 111893480 16 StrikeFontSet>glyphInfoOf:into: 107493580 111893572 16 StrikeFont>ascentOf: 107493580 111893940 16 StrikeFont>hasGlyphOf: 107493580 111894032 16 Character>charCode 107493580 111893940 16 StrikeFont>hasGlyphOf: 107493580 111893940 16 StrikeFont>hasGlyphOf: 107493580 111894032 16 Magnitude>between:and: 107493580 111893940 16 StrikeFont>hasGlyphOf: 107493580 111893572 16 StrikeFont>ascentOf: 107493580 111893480 16 SequenceableCollection>first 107493580 111893480 16 SequenceableCollection>first 107493580 111893480 16 SequenceableCollection>second 107493580 111893572 16 SequenceableCollection>checkedAt: 107493580 111893572 16 SequenceableCollection>checkedAt: 107493580 111893480 16 SequenceableCollection>third 107493580 111893572 16 SequenceableCollection>checkedAt: 107493580 111893572 16 SequenceableCollection>checkedAt: 107493580 111893480 16 SequenceableCollection>fifth 107493580 111893572 16 SequenceableCollection>checkedAt: 107493580 111893572 16 SequenceableCollection>checkedAt:
what is interesting is that StrikeFontSet>displayString:on:from:to:at:kern:baselineY:
does
self glyphInfoOf: (aString at: charIndex) into: glyphInfo. g := glyphInfo first. leftX := glyphInfo second. rightX := glyphInfo third. (glyphInfo fifth ~= aBitBlt lastFont) ifTrue: [ glyphInfo fifth installOn: aBitBlt. ].
Now for example SquenceableCollection>>fifth "Answer the fifth element of the receiver. Raise an error if there are not enough elements."
^ self checkedAt: 5
which does
SquenceableCollection>>checkedAt: index index > self size ifTrue: [self error: 'not enough elements']. ^ self at: index
which does the at: index which would in fact toss an self errorSubscriptBounds: when the primitive discovers a range check issue.
So do we need the checkedAt: logic? Could we just not say fifth ^self at: 5
Of course saying (self at: 5) in displayString:on:from:to:at:kern:baselineY: would be way more efficient.
Other fun things like Rectangle>insetBy: invokes isKindOf: versus saying isThisARectangle or something...
String>convertFromWithConverter: is quite message sending happy.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===