I have a machine dual booted with Arch Linux and Ubuntu (16.04).

I have recently started using the Kakoune text editor, and noticed that its startup time is drastically different depending on which OS I am using. However I believe the underlying problem is not due to kakoune directly.

On startup, kakoune runs a bunch of shell scripts to enable integration with x11 and tmux, git, syntax highlighting/colorschemes, etc. This can be disabled to just load the 'vanilla' editor using the -n flag.

The command: kak -e q will start kakoune, run all startup scripts and exit immediately.

On Arch:
time kak -e q takes 1 second
time kak -n -e q (no shell scripts) finishes in under 20 millis.

On Ubuntu:
time kak -e q takes about 450 millis
time kak -n -e q is again under 20 millis

After trimming the fat and removing some of the startup scripts I did see an improvement on both OS's proportional to the amount removed.

I ran some benchmarks with UnixBench and found that the major differences between the two systems are seen in the 'process creation' and 'shell scripts' tests.

The shells scripts test measures the number of times per minute a process can start and reap a set of one, two, four and eight concurrent copies of a shell scripts where the shell script applies a series of transformation to a data file.

Here is the relevant output. Units in 'loops per second' more is better:

Process creation (1 parallel copy of tests)
Arch:    3,822
Ubuntu:  5,297
Process creation (4 parallel copies of tests)
Arch:   18,935
Ubuntu: 30,341

Shell Scripts (1 concurrent) (1 parallel copy of tests)
Arch:      972
Ubuntu:  5,141
Shell Scripts (1 concurrent) (4 parallel copies of tests)
Arch:    7,697
Ubuntu: 24,942

Shell Scripts (8 concurrent) (1 parallel copy of tests)
Arch:      807
Ubuntu:  2,257
Shell Scripts (8 concurrent) (4 parallel copies of tests)
Arch:    1,289
Ubuntu:  3,001

As you can see the Ubuntu system performs much better.

I have tested using different login shells, terminal emulators, recompiling kakoune, removing unneeded software to clean up the disk, etc. I am certain this is the bottleneck.

My question is: what can I do to further investigate this and improve performance of the Arch Linux system to match Ubuntu? Should I look into tuning the kernel?

Additional notes:

  • both systems use the same type of filesystem (ext4)
  • I tend to use the Archlinux system more, and have noticed performance degrading over time
  • Arch is on /dev/sda1 and is ~200GB. Ubuntu is on /dev/sda2, ~500GB. 1TB HDD.
  • Arch uname -a: Linux ark 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 x86_64 GNU/Linux
  • Ubuntu uname -a: Linux sierra 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


  • Do these tests use a certain shell or the system's default shell? Is /bin/sh linked to the same shell in both distros? Jan 20, 2018 at 6:38
  • You can run an empty shell script through strace -T ./testscript.sh and strace -T ./testscript.sh and compare the output. Jan 20, 2018 at 7:02
  • @HaukeLaging they use /bin/sh, as does kakoune. EDIT: /bin/sh points to bash in archlinux. This might be the reason I will check.
    – anon777
    Jan 20, 2018 at 7:20

3 Answers 3


Debian and Ubuntu use dash as /bin/sh, it's somewhat faster than Bash:

$ time for x in {1..1000} ; do /bin/bash -c 'true' ; done                                                                                                                                                                                                                                                      
real    0m1.894s

$ time for x in {1..1000} ; do /bin/sh -c 'true' ; done 
real    0m1.057s

That's around the same area (in ratio) as your numbers.

Changing /bin/sh to dash instead of Bash in Debian and Ubuntu was greatly because of performance:

The major reason to switch the default shell was efficiency. bash is an excellent full-featured shell ... However, it is rather large and slow to start up and operate by comparison with dash.


  • A note: LC_ALL=C /bin/bash cuts the time from 1.537s to 0.695s on my rig, vs. 0.497s for /bin/dash.
    – jthill
    Mar 17 at 21:08
  • @jthill, that big a difference with just that loop I used above? Curious, it doesn't really even do anything the locale would affect... And I expected that would mostly show the time used for startup. I suppose there's some overhead in loading the locales, and I can see some difference, but not nearly as large. I tried unsettting LANG and all the LC_* envvars, and then ran (export LC_ALL="en_US.UTF-8"; locale; time for x in {1..1000} ; do /bin/bash -c 'true' ; done ) and got 1.60 s for LC_ALL=en_US.UTF-8 vs. 1.48 for LC_ALL=C.
    – ilkkachu
    Mar 18 at 7:09
  • I was leaving off setting it for the non-C, getting my usual environment, LANG=en_US.UTF8 LC_COLLATE=C LC_NUMERIC=C. Doing the unmixed en_US saves about 0.2s on the loop but yeah your exact loop, it's repeatable for me on Arch, LC_ALL=C cuts the startup times dramatically. Bash 5.2.26, maybe they're working on it? Haven't checked the changelogs.
    – jthill
    Mar 18 at 8:14

As explained by ilkkachu, Arch uses bash for /bin/sh, whereas Ubuntu defaults to dash.

To further investigate this, and determine whether this explains the difference, you can configure your Ubuntu system to use bash instead and see if the benchmarks then report similar results to those obtained on Arch. To do this, run

sudo dpkg-reconfigure dash

and select “No”. You can then verify that /bin/sh points to bash, and run your tests.

To restore the default, run the same command again and choose “Yes”.

If this is the reason for the difference in performance, improving Arch to match Ubuntu will be difficult. You could install dash and use that, but you’d likely run into lots of scripts which assume /bin/sh is bash and fail with dash — it took Debian and Ubuntu quite a long time to identify and fix all the issues.


Adding my own answer in case anyone else has the same issue:

When running the for loops in @ilkkachu 's answer from an interactive bash shell with zsh or fish as my login shell, the /bin/bash loop takes about 13 seconds. If I run the loop from a root login shell, or change my login shell to /bin/bash, I achieve results similar to those in @ilkkachu 's answer.

I presume this is because /bin/bash inherits its environment from the login shell (either /bin/zsh or /bin/fish), but I am not exactly sure.

In any event, I solved the issue by changing my login shell to /bin/bash and setting up my terminal to run /bin/fish or /bin/zsh as an interactive shell.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .