GNU bug report logs -
#37241
large performance gap when start+inc specified with 'seq'
Previous Next
Reported by: L A Walsh <coreutils <at> tlinx.org>
Date: Fri, 30 Aug 2019 23:31:01 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]
This bug report was last modified 5 years and 258 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.