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.
