Ranges, Performance, and opApply

Steven Schveighoffer schveiguy at yahoo.com
Mon Oct 31 05:56:21 PDT 2011


On Sun, 30 Oct 2011 15:23:59 -0400, dsimcha <dsimcha at yahoo.com> wrote:

> On 10/30/2011 3:09 PM, Andrei Alexandrescu wrote:
>>> As the opApply body can never be inlined it is a worse choice in  
>>> general.
>>
>> That was my intuition too.
>>
>>
>> Andrei
>
> Just for future reference, LDC **DOES** sometimes inline opApply bodies.

The compiler should almost always be able to inline opApply, as the code  
for the opApply body is always available.

There are few exceptions, such as when opApply is not final, or when it's  
recursive.  I wonder if even in these cases, some sort of "virtual  
inlining" such as pushing the code onto the stack and avoiding using  
function calls would be possible (speaking from naivety, maybe this does  
nothing).  Being able to exploit the fact that a delegate literal is  
always fully available would be nice.

Indeed, opApply should beat the pants off of ranges when the range  
primitives are virtual functions.  But ranges should win when inlining is  
possible in some cases.

There are always going to be use cases for opApply that ranges cannot  
duplicate (such as recursion), and vice versa (such as parallel iteration).

-Steve


More information about the Digitalmars-d mailing list