Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14491
| 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> |
> 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
Re: Unexpected delay in using arguments. Bize Ma <binaryzebra@gmail.com> - 2018-08-14 23:17 -0400
csiph-web