Re: Bash-4.0-rc1 available for FTP
bash_completion is too slow because it does strange things: it parses itself because it wants to emulate the behavior of "-o plusdirs". See https://bugzilla.redhat.com/show_bug.cgi?id=479936 for a preliminary patch. Thanks for pointing this out. This would indeed be a significant improvement! Apparently, bash-completion is very active at the moment. They are currently trying to fix as many bugs as possible, and will then optimize bash-completion for Bash 3.x. Nicolas
Re: Bash-4.0-rc1 available for FTP
Nicolas writes: > Hello, > > I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the > results. > My computer is a Pentium M (running at 600 MHz for the test), running Linux > 2.6.26 with libc6 version 2.7 and Debian bash-completion version 20080705. > The figures are averages over 100 tests. > > Bash 3.2, without bash malloc: > * eval `dircolors`: 0.636s > * source /etc/bash_completion: 0.721s > > Bash 4.0, with bash malloc: > * eval `dircolors`: 0.385s > * source /etc/bash_completion: 41.651s (around 93% of the time is spent in > function find_entry of lib/malloc/table.c) > > Bash 4.0, without bash malloc: > * eval `dircolors`: 0.132s > * source /etc/bash_completion: 0.703s bash_completion is too slow because it does strange things: it parses itself because it wants to emulate the behavior of "-o plusdirs". See https://bugzilla.redhat.com/show_bug.cgi?id=479936 for a preliminary patch.
Re: Bash-4.0-rc1 available for FTP
> Bash versions other than `release' are built with extensive extra arena > and allocation checking enabled in the bash malloc. Thanks for pointing this out. Here are the new results: Bash 4.0, with bash malloc: * eval `dircolors`: 0.138s * source /etc/bash_completion: 0.735s Bash 4.0, without bash malloc: * eval `dircolors`: 0.135s (slightly slower than with debugging on, I checked several times to be sure. This is very surprising...) * source /etc/bash_completion: 0.702s Without bash malloc, the results are close to the results with debugging on. The results with bash malloc are far better now, but still slightly behind those with libc malloc, on my computer. In addition, in builtins/evalstring.c, line 271, an itrace call is not enclosed between #if defined (DEBUG) and #endif, as it should be. With my computer at normal speed (with the 'ondemand' governor), starting a new shell (and running my .bashrc) now takes around 0.4s, while it took 0.6s with Bash 3.2. This is enough to feel a difference! Nicolas
Re: Bash-4.0-rc1 available for FTP
Nicolas wrote: > Hello, > > I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the > results. Thanks. > Bash 4.0, with bash malloc: > * eval `dircolors`: 0.385s > * source /etc/bash_completion: 41.651s (around 93% of the time is spent in > function find_entry of lib/malloc/table.c) Bash versions other than `release' are built with extensive extra arena and allocation checking enabled in the bash malloc. The `find_entry' function is the primary interface to look up the record kept for each allocation. As you can imagine, bash takes quite a performance hit when this kind of allocation debugging is enabled. If the results are acceptable with allocation tracing and debugging on, they should be even better in the release version. If you'd like to experiment right now, you can recompile after disabling the `DEBUG' and `MALLOC_DEBUG' defines in Makefile. (Or you can just rebuild with `make DEBUG= MALLOC_DEBUG='.) > We notice that on my computer, libc6's malloc is definitively faster than > Bash's malloc. Let's not decide that just yet. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.0-rc1 available for FTP
Hello, I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the results. My computer is a Pentium M (running at 600 MHz for the test), running Linux 2.6.26 with libc6 version 2.7 and Debian bash-completion version 20080705. The figures are averages over 100 tests. Bash 3.2, without bash malloc: * eval `dircolors`: 0.636s * source /etc/bash_completion: 0.721s Bash 4.0, with bash malloc: * eval `dircolors`: 0.385s * source /etc/bash_completion: 41.651s (around 93% of the time is spent in function find_entry of lib/malloc/table.c) Bash 4.0, without bash malloc: * eval `dircolors`: 0.132s * source /etc/bash_completion: 0.703s We notice that on my computer, libc6's malloc is definitively faster than Bash's malloc. More interesting is the fact that the various improvements to command substitution have dramatically reduced its execution time (eval `dircolors` is now 4.8 times faster!). Thank you very much for this wonderful new version of Bash! Nicolas
Re: Bash-4.0-rc1 available for FTP
Chet Ramey wrote: Matthew Woehlke wrote: Chet Ramey wrote: f. Changed behavior so the shell now acts as if it received an interrupt when a pipeline is killed by SIGINT while executing a list. Does this mean that $ sleep 60 ; do-something ...will no longer run 'do-something' when ctrl-C'd? Yes. Cool :-). Thanks for that enhancement! -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)
Re: Bash-4.0-rc1 available for FTP
Matthew Woehlke wrote: > Chet Ramey wrote: >> f. Changed behavior so the shell now acts as if it received an interrupt >> when a pipeline is killed by SIGINT while executing a list. > > Does this mean that > $ sleep 60 ; do-something > ...will no longer run 'do-something' when ctrl-C'd? Yes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.0-rc1 available for FTP
Chet Ramey wrote: f. Changed behavior so the shell now acts as if it received an interrupt when a pipeline is killed by SIGINT while executing a list. Does this mean that $ sleep 60 ; do-something ...will no longer run 'do-something' when ctrl-C'd? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)
