self send inliner

Klaus D. Witzel klaus.witzel at cobss.com
Wed Sep 20 06:24:02 UTC 2006


Some quick and dirty real time data points on self sends, obtained during  
a session with "typical" 3.8.1a developer activities. Datapoints where  
taken for (self == thisContext client) sends. Figures reflect the number  
of methods, *not* the frequency of calls!

self callers: 2463
self callees: 2302
either of them: 3413

With a bit more hacking data which reports the class hierarchy distance *)  
could be obtained.

*) between subclass and superclass; example: Array has distance 3 with  
Collection; self sends within the same class have distance 0.

This would reflect self sends which go down or up the hierarchy. Of course  
the report can tell which methods that are.

If you want a report ask me with details.

/Klaus

On Tue, 19 Sep 2006 21:59:32 +0200, Avi Bryant wrote:
> On Sep 19, 2006, at 10:14 AM, Philippe Marschall wrote:
>> 2006/9/18, Jecel Assumpcao Jr <jecel at merlintec.com>:
>>> Avi Bryant wrote:
>>> Has anyone ever played with a simple self-sends inliner?  No de-
>>> inlining when debugging, no post-inlining optimization, no attempt to
>>> deal with polymorphism, just inlining monomorphic self-sends...
>>
>> Well, I'm toying around with something even simpler:
>>
>> - Does not uninline when methods are added. So you need to load all
>> your code first and then recompile it.
>> - Can only implement methods that contain no return or the return is
>> the last statement.
>>
>> Do you have a case study?
>
> I think the Collection hierarchy would be the right place to start.  I  
> was always impressed by how Strongtalk could do things like implement  
> #at: in terms of #at:ifAbsent:.
>
> Avi
>
>





More information about the Squeak-dev mailing list