Hi Bryce,

on Sun, 17 Sep 2006 12:12:36 +0200, you wrote:
>
> Let me summarise my arguments as you have obviously not understood
> them or refuse to respond to them.

Hey, this is it, I appreciate this your summary :)

> 1) Your change complicates the system for everyone. Adding that
> complexity will make it harder to make any future changes in the
> areas effected. One of those areas is the VMs message sending
> code which is critical.

Agreed, this is the price to pay. Perhaps the components of send/return,  
especially #executeNewMethod with its many #ifTrue:ifFalse: on  
primitiveIndex and return's kangaroo, could use a brush up ;-)

> 2) Your changes make the system more complex to all Squeak
> programmers when they are just doing normal development. Having
> nice readable walk backs is important.

Agreed, the debugger needs change.

> 3) Your VM changes add costs to message sends. Message
> sends are more common than do: loops. Thus with both your
> image changes and your VM changes the system may be slower.

Agreed, would you say that we have as yet not considered amortization.

> This is an optimisation, to have any value your change must
> speed up the system not slow it down. Based on my analysis the
> costs will be in the range of 1% to 15% of send speed.

I posted a comparision in the first message. But of course it didn't  
include the cost of all other message sends. I appreciate your analysis 1%  
to 15% but this is just a static, dry run view. I do not expect the cost  
to come close to 1% on average. Amortization is required.

> 4) Your image changes will slow #do: down for all VMs that do
> not have your image changes.

I do not expect primitiveApplyToFromTo's possible before 4.0 and I think  
that older VM's will not run 4.x images out of other reasons.

> I have told you how to avoid the
> performance costs here but the problem is you're trying to side
> step a deliberate language restriction against changing arguments.

You perhaps misunderstood. In Smalltalk every argument value can be  
changed behind your back, whether you like it or not. I do not see this as  
language restriction, that's correct. Everything is an object.

> You are proposing an optimisation that you refuse to demonstrate does
> not slow the system down.

This has nothing to do with unwillingness. I wrote earlier
> It would be interesting to compare the performance figures for platforms  
> other than win32.
And I consider how to measure performance cost of #commonSend and  
#commonReturn.

> To have a case you need to demonstrate that
> the gains to #do: will be greater than the losses on message sends.

Sure, that's the idea.

> Optimisations must provide enough speed improvement to justify the
> cost of living with them and preferably the cost of developing them.

> No-one has yet demonstrated that there is a practical performance
> problem with either our current occurencesOf: or even an
> implementation that used count:.

This would be ignoring the simple benchmarks of Jon's with my follow up  
and the figures I posted in this thread.

> Bryce

Heh, t'was the first dialog without the E...y word (since our first  
meeting in the #squeak channel ;-)

/Klaus