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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#37241: closed (large performance gap when start+inc specified
 with 'seq')
Date: Thu, 05 Sep 2019 10:41:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 5 Sep 2019 11:40:57 +0100
with message-id <3da217d9-deda-8103-14d0-2256d9c01db2 <at> draigBrady.com>
and subject line Re: bug#37241: large performance gap when start+inc specified with 'seq'
has caused the debbugs.gnu.org bug report #37241,
regarding large performance gap when start+inc specified with 'seq'
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
37241: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37241
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: L A Walsh <coreutils <at> tlinx.org>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: large performance gap when start+inc specified with 'seq'
Date: Fri, 30 Aug 2019 16:29:52 -0700

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?

[Message part 3 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 37241-done <at> debbugs.gnu.org
Subject: Re: bug#37241: large performance gap when start+inc specified with
 'seq'
Date: Thu, 5 Sep 2019 11:40:57 +0100

On 04/09/19 21:42, L A Walsh wrote:
> 
> 
> On 2019/09/03 18:51, Pádraig Brady wrote:
>> 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.
> ---
> 	Thanks, um, do you know what the time would have been
> on your machine of the original, non-explicit case, i.e.:
> 
> time seq.new 1e8 >/dev/null

`seq 1e8` is treated the same as `seq 1 1 1e8` on both old and new code.
I.E. a step of 1 was treated specially, even if specified.
I'll push this later. Marking as done.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.