tag: bash

Following up on Saturday's post and various other blog entries about bash. While arguing with Anton about bash being slow, I discovered that /etc/bash_completion was sourced twice when starting a shell on my laptop; once in /etc/bash.bashrc, and once in ~/.bashrc. This is Debian bug #430501 - the suggestion there is that /etc/skel/.bashrc should change to check whether /etc/bash_completion had already been included. So, that saves 0.27 seconds. tim@regulus:~$ time bash -i -c exit exit real 0m0....

Beginning last night, I reinstalled my laptop. Normally, if it were just to clean up some packages, I wouldn't do this - the aim was more to try out removing the disk encryption that I was using, and the effect has been quite dramatic. I worked out a while ago that the device-mapper encryption was slowing down disk access - with it gone, boot times are much shorter (and I don't have to type in a LUKS passphrase)....

So, a benchmark. tim@regulus:~$ time zsh -i -c exit real 0m0.064s user 0m0.048s sys 0m0.008s tim@regulus:~$ time bash -i -c exit exit real 0m0.540s user 0m0.436s sys 0m0.100s Both shells had their respective completion systems enabled. (Without them turned on, bash actually beats zsh... but the times are small enough that it doesn't matter.) These times are with a warm disk cache - the first time through both shells were slower....

Continuing my search for the subtle things that have annoyed me for years about my desktop usage, I want to think about shell startup times. Application startup times have been done to death, I'm sure - it is one of the more obvious areas to work on when improving a desktop application. Evolution's startup time is still appalling, for instance; I count five seconds before I get a GUI, and many more before I see any email....