--- Begin Message ---
|
Subject: |
large performance gap when start+inc specified with 'seq' |
|
Date: |
Fri, 30 Aug 2019 16:29:52 -0700 |
|
User-agent: |
Thunderbird |
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?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#37241: large performance gap when start+inc specified with 'seq' |
|
Date: |
Thu, 5 Sep 2019 11:40:57 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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
--- End Message ---