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