bug#37241: large performance gap when start+inc specified with 'seq'

[Pádraig Brady]

On 31/08/19 00:29, L A Walsh wrote:
> Was looking at some large sequences and the time they took
> and found that while end-point only was fast:
> 
> declare -x TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)"
> 
>> time seq 1e8 >/dev/null
> 0.75sec 0.74usr 0.01sys (99.77% cpu)
> 
> Trying just to generate only odd numbers:
>> time seq 1 2 1e8 >/dev/null
> 24.70sec 24.64usr 0.01sys (99.82% cpu)
> 
> took way longer.
> 
> Shouldn't the 2nd case take about half as long as
> the first?  They are both adding integers though in
> 2nd case, its skipping the "even"s on output.
> 
> If it was some floating point calculation needed, I might not
> have blinked, but both an integer sequence with the 2nd
> being half as long?  Should half the numbers take almost 33x
> longer?

Yes we could be better here.
Attached is a fairly simple improvement:

$ time seq.new 1 1 1e8 >/dev/null
real    0m1.516s

$ time seq.new 1 2 1e8 >/dev/null
real    0m0.834s

$ time seq.orig 1 2 1e8 >/dev/null
real    0m40.435s

It might be improved further with BCD addition of the step string,
but this should be good for now.

cheers,
Pádraig

seq-fast-step.patch
Description: Text Data