std.partition is fucked

Lutger lutger.blijdestijn at gmail.com
Wed May 13 11:24:51 PDT 2009


Andrei Alexandrescu wrote:

> Sean Kelly wrote:
>> Andrei Alexandrescu wrote:
>>>
>>> The performance of std.sort is back to normal - still slower than the 
>>> built-in sort (but not by orders of magnitude), probably because 
>>> bumping ranges is at a disadvantage.
>> 
>> The built-in sort uses an internal stack rather than recursion, which 
>> makes its performance on a best-case dataset hard to beat.  I finally 
>> satisfied myself by having a constant time overhead vs. the built-in 
>> sort for best-case and beat it by polynomial time for worst-case (the 
>> built-in sort doesn't adapt to worst-case datasets very well).
> 
> Yeah, I saw that fixed-size stack. I'm not sure whether that's 
> responsible for much of its performance, one of these days I need to 
> measure. My speculation is that the depth of the stack is small enough 
> to not really contribute much to the running time.
> 
> Andrei

Some time ago I reinvented these wheels for study purpose. A custom stack was a little faster but not that much. std.swap can't be inlined because it uses ref params, that cost also a bit since it's called 
many times. Switching to another sort if a certain recursion depth is reached helped, but mostly in degenerate cases. 

I still have the thing somewhere, it is about twice as fast as builtin sort. It's not a lot of work but I could dig it up and provide some timings if you want. 












More information about the Digitalmars-d mailing list