Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Bob Proulx Newsgroups: gnu.bash.bug Subject: Re: Unexpected delay in using arguments. Date: Tue, 14 Aug 2018 15:50:36 -0600 Lines: 25 Approved: bug-bash@gnu.org Message-ID: References: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1534283444 12354 208.118.235.17 (14 Aug 2018 21:50:44 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash To: Bize Ma Envelope-to: bug-bash@gnu.org Mail-Followup-To: Bize Ma , bug-bash Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14487 I followed along through the script: > m=20000 ... > test1() { ... Eventually I got to this line: > set -- $(seq $m) At that line I see that bash must allocate enough memory to hold all of the numbers from 1 through 20000 in memory all at one time. That is very inefficient. That is at least 100K of memory. $ seq 20000 | wc -c 108894 Of course I assume this is only a proxy simpler reproducer for the actual problem program but just the same it is almost always possible to refactor a program into a different algorithm that avoids the need to enumerate so many arguments in memory. I suggest refactoring the program to avoid the need for this memory stress. Bob