Subject: bug#37241: closed (Re: bug#37241: large performance gap when start+inc specified with 'seq')

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 05 Sep 2019 10:41:02 +0000

Your bug report

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

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
37241: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37241
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#37241: large performance gap when start+inc specified with 'seq'
From: Pádraig Brady <[email-masked]>
To: L A Walsh <[email-masked]>
Cc: [email-masked]
Date: Thu, 5 Sep 2019 11:40:57 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: large performance gap when start+inc specified with 'seq'
From: L A Walsh <[email-masked]>
To: Coreutils <[email-masked]>
Date: Fri, 30 Aug 2019 16:29:52 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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?