[phobos] std.algorithm.sort slow as molasses

[Leandro Lucarella]

Brad Roberts, el  2 de julio a las 13:43 me escribiste:
> On Fri, 2 Jul 2010, Leandro Lucarella wrote:
> 
> > See bug 859
> > http://d.puremagic.com/issues/show_bug.cgi?id=859
> > 
> > Is not a great bug report but there is a little test case. This is
> > mostly D1 because of ranges, but using opApply with the current state of
> > inlining is almost impossible for performance-aware applications.
> 
> That one is on my radar already.  I'm going to finish working on the 
> migration of the dmd test suite before digging back into ticket, but this 
> one is high on my list for what to tackle next.

Thanks (for both =).

> Is it directly impacting this specific case (I haven't looked at the code 
> involved)?

I don't know, I've hit this problem working in the GC, and as I said in
this post, the (lack of) inlining is really showing:
http://www.llucax.com.ar/blog/blog/post/-611dc288

I think my main problem was with opApply(), since the delegate passed to
opApply() is used in a loop by definition, inlining that delegate is
really important. Another reason to inline it (even when is a large and
heavy function is it will be always an anonymous delegate (unless you
call opApply() manually), so you are not even saving code size here.
opApply() delegates should be inlined *always* IMHO, I don't know if
it's easy to make a special case though.


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Wenn ist das nunstück git und slotermeyer? Ja!
Beiherhund das oder die Flipperwaldt gersput!
	-- Monty Python (no leer si sabés alemán)