protocol for using InputRanges

[Marc Schütz" <schuetzm at gmx.net>]

On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
> On Thursday, 27 March 2014 at 15:45:14 UTC, Andrei Alexandrescu 
> wrote:
>> On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
>>> On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
>>>>> BTW, I think there has been recent talk about not focusing 
>>>>> on dust when
>>>>> we are laying bricks. This would have my vote as useless 
>>>>> dust. This does
>>>>> not solve the problem of streams-as-ranges, because streams 
>>>>> don't make
>>>>> good ranges. It doesn't really solve any problems as far as 
>>>>> I can tell.
>>>>
>>>> I think byXchar are important and are not streams. -- Andrei
>>>
>>> What's broken about those?
>>
>> Speed.
>
> I call shenanigans. This is the code:
>
>             @property bool empty()
>             {
>                 if (nLeft)
>                     return false;
>                 if (r.empty)
>                     return true;
>
> If you initialized the next element in both constructor and 
> popFront, then you'd get rid of both these checks.
>

... but of course lose laziness.

> Furthermore, popFront() has a guaranteed "1 call" per element. 
> Weareas "empty" and "front" may be called several times in a 
> row for a single element.
>
> If you want efficiency, stop being "member-wise" lazy, and put 
> some eagerness in your code.
>

Does a flag "isInitialized" even have an effect on performance 
where it matters?

It should only be relevant in tight loops, and there I expect a 
moderately well-working optimizer to inline calls to `empty` and 
`front`. It can then see that it has just set "isInitialized" to 
true/false, and remove the checks completely, effectively 
generating code as if the value were only fetched/computed in 
`empty`. That only leaves the larger struct size as a potential 
problem. However I've seen LDC being able to "decompose" a struct 
into separate variables, so I guess it can remove the unnecessary 
member in our case.

In other situations, where you already have more complex code, an 
additional conditional branch will not have as much weight anyway.

Does somehow have numbers for realistic programs, with 
GDC/LDC/DMD? I suspect this entire discussion is moot, because we 
can easily have non-eagerly initialized ranges without 
sacrificing performance in most situations.