Proposal: takeFront and takeBack

[Roman D. Boiko]

On Wednesday, 4 July 2012 at 22:02:28 UTC, deadalnix wrote:
> Le 04/07/2012 21:45, Jonathan M Davis a écrit :
>> On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
>>> 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).
>>
>> I should clarify that. It's taking 70 - 80% as long to use 
>> consumeFront to
>> iterate over a string than it is to iterate using popFront and 
>> getting front
>> on every iteration. The way I worded that could imply that it 
>> was taking 20 -
>> 30% as much time, which would be a _much_ larger improvement 
>> than I'm actually
>> seeing.
>>
>> - Jonathan M Davis
>
> The win is significant indeed.

I'm not sure. Let's speculate a bit with some almost random 
numbers.

E.g., suppose that some test without user code in a loop takes 70 
(or 80) ms (per iteration) instead of 100. Or, assuming that some 
optimization of front / popFront would make it proportionally 
twice faster, 35 instead of 50.

It may be significant, if user code inside the loop is relatively 
fast, but that is not often the case. Let's assume that it takes 
30 ms (that looks like pretty fast). So overall it would be (70 + 
30) vs (100 + 30) before front / popFront optimization, and (35 + 
30) vs (50 + 30) after (huge optimization). The latter is 65 vs 
80, which is about 81 vs 100 (instead of 70 vs 100 before 
optimization). If user code was slower, impact of front / 
popFront optimization would be relatively larger, and vice verse.

I make no conclusions, because have not run any benchmarks to 
estimate how complex the code should be to take those 30 ms. Such 
benchmarks would be valuable for discussion.