Proposal: takeFront and takeBack

[Andrei Alexandrescu]

On 7/4/12 3:19 PM, Jonathan M Davis wrote:
>> In theory all of these redundant operations can be done away with
>> optimization techniques, but probably some aren't. So we should look
>> first at optimizing this flow heavily before looking at an API addition
>> that has disadvantages in other dimensions.
>
> The problem is that there are inherent costs in calling both front and
> popFront which can be avoided if they're done as a single operation. front
> must call decode (or code that does its equivalent), and popFront must call
> stride (or code that does its equivalent). There are duplicate calculations
> there that cannot be avoided as long as they're separate operations.

This pretty much rehashes stuff that has been discussed already. (I'm 
only mentioning this because it only adds uninformative chaff to an 
already long message, which discourages one from reading it.)

> Now, if want to argue that if we can get that cost down low enough adding
> consumeFront is not worth the extra burden on the range API and the developers
> using it, then okay. That's a valid argument, and looking to further optimize
> front and popFront is beneficial regardless.

That too :o).

> But at present, I'm seeing a performance improvement of approximately 70 - 80%
> in iterating over strings with consumeFront rather than front and popFront
> (depending on the compiler flags and strings used).

Great. Could you please post some code so we play with it? Thanks.

> And odds are, if you're
> optimizing front and popFront, then you'll likely get the same optimizations
> in consumeFront.

That reasoning is only partly applicable. To make a long story short 
many of the optimizations I mentioned will indeed accelerate both 
approaches, but will also reduce the speed difference between them 
because they'll benefit front/popFront twice as much.


Andrei