asyncial
This blog post documents really quick, how you can get URxvt to be ready in less time. I measured the time, my computer needed, to start instances of URxvt to a usable shell and close it again for 25 times. I tried that with bash, dash and zsh with and without oh-my-zsh. It measured it with time(1). My test script looks like this:
#! /bin/sh
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
do urxvt -e 'dash'
done
Of course, ‘dash’ needs to be replaced with the shell, you want to use. It’s not and a beautiful script, and I think, I will redo it sometime, making it more flexible.
The configs for all shells just consisted of exit, so they close immedietly after they’re ready, with the exception of my oh-my-zsh-config, which is the one, I use at the moment, but with an exit appended in the last line.
I used MASCHINE, my notebook, as platform for the tests. Look at its specs in my about page.
What to do
So, how do we get the start up faster? Throw out stuff we don’t need. For example the Perl support. I don’t use any extensions or scripts, so I can safely disable it. The great thing is, URxvt lets you do this, without having you recompile it by hand. You can just append the following setting to your ~/.Xresources:
! DISABLE PERL FOR BETTER PERFORMANCE AND SECURITY !
URxvt.perl-ext:
URxvt.perl-ext-common:
This disables the startup of the built-in perl interpreter. But can we get it even faster? Of course. URxvt comes with an optional client-server model. So, if we run the urxvtd daemon at boot time, we can start its client urxvtc with insane time improvements. Just add this to your systems autostart file:
urxvtd -q -o -f &
This starts the daemon in the background and keeps it exclusive for the running X instance. One could this consider cheating, because urxvt is kind of started already, but that is another topic.
How fast it is
Remember that this is the time 25 instances of URxvt need to launch.
*As calculated with: [urxvt] * 100 / [urxvtc without perl]
Conclusion
We can see, that we now only need ~10-15 % of the time, we once needed to start a terminal window. In the case of my config, that is only a difference of about 0.15 second (for a single run), but it has gone from noticeable to unnoticable. I think, the difference could be even more important, if I had a traditional HDD. I can think of another optimization, which is recompiling the application without all unneeded features and with custom CFLAGS, to optimize for your processor architecture, but that might be overkill. However on a weaker system like the Raspberry Pi, it could be an option.