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 at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===