Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14491

Re: Unexpected delay in using arguments.

From Bize Ma <binaryzebra@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: Unexpected delay in using arguments.
Date 2018-08-14 23:17 -0400
Message-ID <mailman.5124.1534303082.1292.bug-bash@gnu.org> (permalink)
References <CAFra36j=UuqHv2Spp26ebAW0dRW+KsgNS21hZJrwuku9QUayWw@mail.gmail.com> <20180814123113518879862@bob.proulx.com>

Show all headers | View raw


> Of course I assume this is only a proxy simpler reproducer
> for the actual problem program

Of course this is a "reproducer" of the issue.

> 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.

As you say: "almost".

Take a look at the Stéphane Chazelas example to convince yourself.



2018-08-14 17:50 GMT-04:00 Bob Proulx <bob@proulx.com>:

> 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
>

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: Unexpected delay in using arguments. Bize Ma <binaryzebra@gmail.com> - 2018-08-14 23:17 -0400

csiph-web