ClassTestCase

>
> On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
>
>> On Mon, 24 May 2010, Lukas Renggli wrote:
>>
>>>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the
>>>> moment, so that should be preferred in core packages.
>>>
>>> It should not be preferred or changes unless you can prove a real
>>> performance benefit. I still haven't seen a single realistic benchmark
>>> with real code (from Pharo, Seaside, Pier, ...) where you can measure
>>> a real difference between these 4 variants.
>>
>> Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images.
>>
>
>
> Well what is going on is that you are changing the
> foo isNil ifTrue:
> which is a message send for the isNil into a
> foo == nil ifTrue:
> which then does an object identity check in byte codes.
>
> Because messages sends are *slow* removing one from millions of executions does improve things.
>
> However what be more clever is changing the compiler to optimize the use of isNil so you maintain readability without a performance penalty.

>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>

> On Mon, 24 May 2010, John M McIntosh wrote:
>
>>
>> On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
>>
>>> On Mon, 24 May 2010, Lukas Renggli wrote:
>>>
>>>>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at
>>>>> the
>>>>> moment, so that should be preferred in core packages.
>>>>
>>>> It should not be preferred or changes unless you can prove a real
>>>> performance benefit. I still haven't seen a single realistic benchmark
>>>> with real code (from Pharo, Seaside, Pier, ...) where you can measure
>>>> a real difference between these 4 variants.
>>>
>>> Well, just replace all uses of == nil and #ifNil:, etc with isNil and
>>> isNil ifTrue: etc. Then get some benchmarks which you accept as realistic
>>> and run them in both images.
>>>
>>
>>
>> Well what is going on is that you are changing the
>> foo isNil ifTrue:
>> which is a message send for the isNil into a
>> foo == nil ifTrue:
>> which then does an object identity check in byte codes.
>>
>> Because messages sends are *slow* removing one from millions of executions
>> does improve things.
>>
>> However what be more clever is changing the compiler to optimize the use
>> of isNil so you maintain readability without a performance penalty.
>
> Is "isNil" really more readable than "== nil"?
>
>>
>> Also consider 'first' 'second'
>>
>> Well and the case of the simple accessor
>>
>> self foo ifTrue:[]
>> where
>> foo
>> ^foo
>
> Inlining more methods is a bad idea IMHO. It makes the compiler and the
> decompiler more complex. An inlining JIT is the real solution.
>
>
> Levente
>
>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh <[hidden email]>   Twitter:
>>  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>
>> ===========================================================================
>>
>>
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>