Just to confirm that the delays were removed on the release version.
Thanks
Chet Ramey () wrote:
In the development distributions, always available at
>
> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz
>
> Or you could just clone the git tree.
>
Many thanks, found and
On 1/1/19 9:57 PM, Bize Ma wrote:
> Chet Ramey (mailto:chet.ra...@case.edu>>) wrote:
>
> It's in CWRU/CWRU.chlog in the development distributions
>
>
> I am sorry but I have been unable to find either the source code
> or the change log, either at the university site or by looking with googl
Chet Ramey () wrote:
> It's in CWRU/CWRU.chlog in the development distributions
>
I am sorry but I have been unable to find either the source code
or the change log, either at the university site or by looking with google.
However, I have made some tests. Yes, the deeper internal delay
with argu
On 12/28/18 10:58 PM, Bize Ma wrote:
> Chet Ramey (mailto:chet.ra...@case.edu>>) wrote:
>
> On 12/23/18 12:07 PM, Bize Ma wrote:
>
>
> {...}
>
>
> > Have you been able to "take a look" ?
>
> Yes, as a matter of fact. Look at the changelog for the day or two around
> the date
Chet Ramey () wrote:
> On 12/23/18 12:07 PM, Bize Ma wrote:
{...}
> > Have you been able to "take a look" ?
>
> Yes, as a matter of fact. Look at the changelog for the day or two around
> the date of the referenced messages.
>
I am pretty sure that I will not understand the finer details of t
On 12/23/18 12:07 PM, Bize Ma wrote:
> Chet Ramey (mailto:chet.ra...@case.edu>>) wrote:
>
> On 8/15/18 3:36 AM, Bob Proulx wrote:
>
> > It does look like bash can be more efficient with argument handling.
> > Since, for example, dash does it.
>
> Yes, it just needs new primitives
Chet Ramey () wrote:
> On 8/15/18 3:36 AM, Bob Proulx wrote:
>
> > It does look like bash can be more efficient with argument handling.
> > Since, for example, dash does it.
>
> Yes, it just needs new primitives to do it. The existing code for managing
> the saved positional parameters has been in
2018-08-15 3:36 GMT-04:00 Bob Proulx :
> Bize Ma wrote:
>
> I still believe that to be true.
You are entitled to have an opinion, even if incorrect.
> Since you haven't shared what the
> actual task is there is no way for us to propose any counter example
> improvements. So "almost" is as f
On 8/15/18 3:36 AM, Bob Proulx wrote:
> It does look like bash can be more efficient with argument handling.
> Since, for example, dash does it.
Yes, it just needs new primitives to do it. The existing code for managing
the saved positional parameters has been in bash since the pre-1.0 days and
i
Bize Ma wrote:
> > 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".
I still believe that to be true. Since you haven't shared what the
actual task is th
> 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
2018-08-14 11:25 GMT-04:00 Chet Ramey :
> On 8/12/18 3:16 AM, Bize Ma wrote:
> > Try this script:
> (...)
> Which is a thousand times slower.
>
> If you build a profiling version of bash, you'll find that about 75% of
> that time is spent copying the list of arguments around
I just don't see wh
2018-08-14 11:25:04 -0400, Chet Ramey:
[...]
> If you build a profiling version of bash, you'll find that about 75% of
> that time is spent copying the list of arguments around, since you have
> to save and restore it each time you call f1. Looking at making that more
> efficient has been a low-lev
I followed along through the script:
> m=2
...
> 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 2 in memory all at one time. That
is very inefficient. That
On 8/12/18 3:16 AM, Bize Ma wrote:
> Try this script:
>
> #!/bin/bash
> TIMEFORMAT='%R'
>
> n=1000
> m=2
>
> f1 () { :; }
>
> f2 () { i=0; time while [ "$((i+=1))" -lt "$n" ]; do : ; done
> i=0; time while [ "$((i+=1))" -lt "$n" ]; do f1
Yes Greg, Please read the expanded source question, bash 5 with (and
without) bash-malloc has been tested.
https://unix.stackexchange.com/q/462084/265604
The problem with arguments is still present.
2018-08-13 9:37 GMT-04:00 Greg Wooledge :
> On Sun, Aug 12, 2018 at 03:16:34AM -0400, Bize M
On Sun, Aug 12, 2018 at 03:16:34AM -0400, Bize Ma wrote:
> Which is a thousand times slower.
> Bash 5 is even worse
Pre-release bash sources use a debugging-friendly (slow) malloc. Or
something. Damn, google is not helping me out here.
Try this script:
#!/bin/bash
TIMEFORMAT='%R'
n=1000
m=2
f1 () { :; }
f2 () { i=0; time while [ "$((i+=1))" -lt "$n" ]; do :; done
i=0; time while [ "$((i+=1))" -lt "$n" ]; do f1; done
}
test1() { set -- $(seq $m)
18 matches
Mail list logo
