Tim Retout's www presence

Shell startup times, part 2

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.270s
user	0m0.240s
sys	0m0.032s

This is still ages when compared to zsh. A solution is proposed in Debian bug #467231 - the functions could be loaded dynamically when they are first used, instead of all at once. I may try this next.

One sandwich and cup of tea later: it works, and bash now beats zsh's time.

tim@regulus:~$ time bash -i -c exit
exit

real	0m0.047s
user	0m0.036s
sys	0m0.004s

Posted: 24 Mar 2008 00:00 | Tags: Planet WUGLUG, Planet UWCS, shell, bash, zsh | Comments (1)

Shell startup times

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. And the numbers stay roughly the same when repeating.

Posted: 22 Mar 2008 00:00 | Tags: Planet WUGLUG, Planet UWCS, bash, zsh, shell | Comments (0)

Encryption and disk access

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). GNOME loads a lot faster. Additionally, bash starts a lot quicker than it did. I suspect loading the bash completion routines takes quite a bit of disk access. Update: No, I just didn't have the bash-completion package installed. Bash is still slow. GNOME is still faster, though... for now.

So, I will probably keep my new install. I need to investigate encrypting a USB device and integrating that nicely with GNOME and gpg.

Posted: 22 Mar 2008 00:00 | Tags: Planet WUGLUG, Planet UWCS, desktop, bash | Comments (0)

Desktop annoyances - getting a prompt

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. Still, in the case of my bloated email client, it doesn't matter that much - I generally start it once a day, at 9am, when I need coffee anyway. It then proceeds to hang around in the background. It would certainly be nice for applications in general to start more quickly, but it's not the cause of these subconscious feelings of annoyance that I want to pin down.

Far more important than my email client are my terminal windows. One of the attractions of evilwm was that starting a terminal window was the focus of the entire window manager - the design is entirely motivated towards getting that window up as fast as possible, rather than aesthetics like window borders. However, these days I'm typically waiting for over a second to get a shell prompt. This is critical - when starting a terminal window, I'm usually about to perform a series of commands, and will really be paying attention to that lag.

There are two areas to consider: the time to start the terminal itself, and the time to start the shell inside the terminal. The shell startup time has been causing the biggest wait - bash itself starts very quickly, but turning on bash completion routines adds almost a second to the delay. Trying zsh out with completion enabled, it seems slightly better - maybe one-third of a second on a warm start. (Idea: add

PROMPT='%n@%m:%~$ '
autoload -U compinit
compinit

to ~/.zshrc and chsh away from bash. It's pretty similar.) This is the best argument for switching that I have seen so far.

The GNOME Terminal is relatively nice, and recent versions seem fast enough to start that changing terminal isn't going to make a significant difference. (Prove me wrong.) Some things about my desktop habits could be improved, though: I have a tiny icon on the panel to launch a terminal, and must be spending ages in mouse movements to start each instance. This is just lag in a different form. So, I've now deleted the icon and set a keyboard shortcut - GNOME has the option to set one, but none by default. Second, perhaps sometimes I should be using terminal tabs instead of opening more terminals - it depends on the task. I haven't thought of a cunning way to force myself to do that yet.

I'm now down to around a second to get an open shell prompt in GNOME without moving my hands from the keyboard, which is a lot better. I can still manage to start typing in the window before the shell appears, though, so I suspect some further work is needed on this.

Posted: 19 Dec 2007 00:00 | Tags: Planet UWCS, Planet WUGLUG, desktop, bash, zsh | Comments (0)