From: Eric Hodel <drbrain@...7.net>
Date: 2007-10-09T01:33:31+09:00
Subject: Re: #sort_by and #sort_obj

On Oct 8, 2007, at 02:51 , Robert Klemme wrote:
> 2007/10/8, Eric Hodel <drbrain@segment7.net>:
>> My primary goal was reducing the number of method calls and objects
>> created, boosting speed.
>
> I'm afraid the performance issue is not that easy: I can imagine where
> the <=> approach is more efficient. Here's the reason: with #sort_by
> you need to keep *all* keys in memory for the whole sorting process
> which can cost a lot of memory.  Creating those for pairwise
> comparison (as with <=>) is more CPU intensive because more temp
> arrays have to be created but the overall memory usage might be lower
> because they are kept during a single comparison operation only (see
> also Rick's benchmark). Allocating that much memory from the OS for
> the #sort_by case might actually slow the sorting down dramatically.

Profiling indicated a significant amount of time was spent in #<=>  
which created more objects and called more methods than #sort_by.   
Replacing #sort with #sort_by and #sort_obj reduced both.  Creating  
fewer objects and using less memory aren't the same thing.

(Also, Rick's benchmark shows Array#sort cheating more than any other  
effect.)

>> The downside to this is that you can't sort heterogeneous  
>> collections using #sort_obj.  When sorting using #<=> this would  
>> be easier.
>
> Not necessarily because the <=> operators might not be able to work
> with elements from the other types and thus sorting might fail as
> miserably. :-)

#<=> usually does the right thing, raising ArgumentError or returning  
nil on incomparable objects, where if you use #sort_obj with  
incomparable objects you may get bogus results.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars