Hi Eliot,

On Tue, 28 Feb 2017, Eliot Miranda wrote:

> Yes, I chose to only inline when a comparison operator is followed by a conditional branch.  So any of #= #~= #== #~~ #> #< #>= #<= if used to compute a value will be compiled into a real send  That could be
> a mistake.  Let me know if you think it will be critical to performance.  The notion is that inlining the branch saves a lot (reifying the result, testing the result for being true, false or something else),
> but inlining just to obtain the result saves only the inline cached send overhead.  That could be the wrong call, but that's what I decided to do back in 2009.

I see no reason not to inline those comparisons. Currently you get 
faster code if you add ifTrue: [ true ] ifFalse: [ false ] to such 
conditions, which is counterintuitive.
An example for this is #isSeparator. The new version

 	| integerValue |
 	(integerValue := self asInteger) > 32 ifTrue: [ ^false ].
 	integerValue
 		caseOf: {
 			[ 32 "space" ] -> [ ^true ].
 			[ 9 "tab" ] -> [ ^true ].
 			[ 13 "cr"] -> [ ^true ].
 			[ 10 "line feed" ] -> [ ^true ].
 			[ 12 "form feed"] -> [ ^true ] }
 		otherwise: [ ^false  ]

is quicker than the second to last version

 	| integerValue |
 	(integerValue := self asInteger) > 32 ifTrue: [ ^false ].
 	integerValue
 		caseOf: {
 			[ 32 "space" ] -> [ ^true ].
 			[ 9 "cr" ] -> [ ^true ].
 			[ 13 "tab"] -> [ ^true ].
 			[ 10 "line feed" ] -> [ ^true ] }
 		otherwise: [ ^integerValue = 12 "form feed" ]

The only difference is that the last check got its own branch in the new 
version.

Levente