We're still not on the same page.

You seem to have some ideological objection to inlining that

I am completely failing to comprehend.

Just because a procedure call (message send) is inlined doesn't

in the least mean it *isn't* a procedure call (message send),

just as compiling a procedure call (message send) as a jump

(last-call optimisation) doesn't mean it *isn't* a procedure

call (message send).

By the way, forget about "40 years ago".

I just did an experiment in Pharo 9, and found that

using "_ ifNotNil: " instead of "_ izNil ifFalse: "

-- where izNil is a non-inlined self == nil --

gave a 10% speedup, in a test code where real work was going

on as well.

As for turning off all inlining, what do you think that would

do to #ifFalse:ifTrue: and its relatives?�� 

On Thu, 17 Mar 2022 at 08:34, <sean@clipperadams.com> wrote:

To start with, why do you CARE whether a particular method is inlined or not?
I care because it makes ��everything is a message�� a lie! And I suspect (no proof and could be wrong) it��s an optimization that only made sense with the hardware constraints of 40+ years ago. Arguing against premature optimization is hardly something I just made up ;-)
This makes absolutely no sense to me. What makes you think that the combination "_ isNil ifFalse: [_]" will NOT be inlined?
I may have been unclear. My intent was to communicate: ��I��d like to stop ALL* inlining of messages by default if possible��
*or as many as practical
The thing that rings loud alarm bells for me is there being "long chains" in the first place.
I agree that it is in general a smell, but long chains was tangential to the intention above
Can you give an example?
I don��t know if I can think of one that��s not contrived�� Wrapping something external? Squeak��s AppleScript support used to mirror the underlying AS, which is pretty much exactly that.
In my own programming, I've generally found that nils turning up in the middle of a chain indicates a serious design error somewhere.
Agreed. See smell comment above.