Re: Bash-4.0-rc1 available for FTP
Nicolas niko...@gmail.com 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
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)
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: 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)
