GNU bug report logs - #37241
large performance gap when start+inc specified with 'seq'

Previous Next

Package: coreutils;

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

From: Pádraig Brady <P <at> draigBrady.com>
To: L A Walsh <coreutils <at> tlinx.org>, 37241 <at> debbugs.gnu.org
Subject: bug#37241: large performance gap when start+inc specified with 'seq'
Date: Wed, 4 Sep 2019 02:51:16 +0100
[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.