Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Eric Blake <eblake@redhat.com>
Newsgroups: gnu.bash.bug
Subject: Re: Performance bug of {1..1000000}?
Date: Mon, 9 Mar 2020 11:41:05 -0500
Organization: Red Hat, Inc.
Lines: 32
Approved: bug-bash@gnu.org
Message-ID: <mailman.2342.1583772075.2412.bug-bash@gnu.org>
References: <CABrM6wmte=vqL1a8aHwLidDzcaUx3=G+n3ZsOz0TweHVFeQLjg@mail.gmail.com> <e68a3a71-d89e-92ce-599e-d5d3ec10ebdd@redhat.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
To: Peng Yu <pengyu.ut@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <CABrM6wmte=vqL1a8aHwLidDzcaUx3=G+n3ZsOz0TweHVFeQLjg@mail.gmail.com>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:16004

On 3/7/20 10:39 AM, Peng Yu wrote:
> See the following run time comparison. {1..1000000} is slower than
> $(seq 1000000).
> 
> Since seq involves an external program, I'd expect the latter to be
> slower. But the comparison shows the opposite.
> 
> I guess seq did some optimization?

seq does not have to store the entire sequence in memory. As it outputs 
things to stdout (and the other end of the pipeline consumes that 
output), seq can forget what it has previously done.

Bash, on the other hand, computes the entire expansion in memory prior 
to proceeding to use that expansion.  It is the cost of memory 
allocation and increased memory usage that slows bash down.

> 
> Can the performance of {1..1000000} be improved so that it is faster
> than $(seq 1000000)?

Not without someone writing a patch.  Are you volunteering?  But in 
general, we don't recommend trying to make bash do expansions like that, 
when it is already more efficient to use other means of iteration that 
do not require bash to keep the entire sequence in memory.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org