Skip to content

Performance

leo-arch edited this page Feb 19, 2026 · 90 revisions

Table of contents

1) Statistics

a) Memory usage

Data retrieved with htop (resident memory in megabytes)

Application Listing 100 files Listing 100,000 files
ranger 31.8 550
xplr 9.7 137
lf 13.1 118
clex 4.7 79
fff 4.3 79
yazi 25.2 60
broot 12 --fails--
mc 9.7 47
joshuto 8.2 39
vifm 9.4 37
clifm 6.2 35
nnn 3.8 11
cfiles 3.6 7.5

b) Disk usage

Data retrieved with du

b.1) Binary size

Binary Size (KiB)
/usr/bin/yazi 21844
/usr/bin/broot 11828
/usr/bin/joshuto 7280
/usr/bin/xplr 5976
/usr/bin/lf 5816
/usr/bin/vifm 1816
/usr/bin/clifm 11321
/usr/bin/mc 1016
/usr/bin/clex 420
/usr/bin/nnn 124
/usr/bin/cfiles 44

1 If compressed via upx(1) we get a much smaller binary size: 404k.

b.2) Package size

Data retrieved with pacman -Qi

Package Installed size
broot 12.18 MiB
yazi 23.19 MiB
mc 7.07 MiB
joshuto 7.11 MiB
lf 5.72 MiB
xplr 6.13 MiB
vifm 3.23 MiB
ranger 2.61 MiB
clifm 1.49 MiB
clex 439.20 KiB
nnn 363.87 KiB
cfiles 45.43 KiB
fff 45.39 KiB

c) Performance

c.1) SysCalls (listing 3,930 files)

Data retrieved with strace -c

Application Syscalls
cfiles 126,760
joshuto 109,386
lsd 80,205
xplr 34,274
fff 13,092
clifm 10,1411
ranger 9,974
clex 9,188
mc 5,723
eza 5,594
broot 5,208
ls 4,587
nnn 4,143
clifm (light) 2,269
lf 422

1 A third of these syscalls is used to check for file capabilities. If you don't need this check (most file managers have it disabled by default), you can run with --no-file-cap (note that on non-Linux systems this check is never performed). Without this check, the number of syscalls drops to 6,163.

c.2) Listing time:

Data retrieved with /bin/time -p.

clifm vs eza (listing 100,000 files)

a. Normal mode

Command Real time User time Sys time
clifm --ls 0.95 0.31 0.49
eza 1.06 0.62 0.38

b. Long/detail mode

Command Real time User time Sys time
clifm --ls -l 2.57 0.82 0.89
eza -l 2.73 1.48 1.41

2) Optimization

Getting some extra performance

As you can see, clifm is by itself quite fast by default. But if speed is still an issue, it is possible to get some extra performance:

1. Disable the file counter, used to print the number of files contained by listed directories. Disabling this option produces a nice performance boost.1

2. Disable some features: icons (if enabled), columns, file sorting, directories first, file-capabilities check, file-extension check, symlinks resolution, Unicode, colors, and, if already running without colors, file-type indicators (classification):

clifm --no-colors --no-columns --no-classify --no-file-counter --no-unicode --no-dirs-first --sort=none --no-file-cap --no-file-ext --no-follow-symlinks

3. Run in light mode

4. Limit listed files. Because listing lots of files could be expensive and time consuming, you can also try to limit the number of files printed for each visited directory (see the mf command).

5. Run in stealth mode

6. Compile in/out a few features:

a) Compile with `-D_TOURBIN_QSORT` to use Alexey Tourbin faster qsort implementation instead of **qsort(3)**. \
b) Compile out features you don't need to get a bit smaller, and thereby faster, executable. For example, to compile out icons and translation support:
clang ... -D_TOURBIN_QSORT -D_NO_GETTEXT -D_NO_ICONS ...

For more information consult the compiling features in/out section.

1 Disable the files counter either via the --no-files-counter command-line option, the FilesCounter option in the configuration file or the fc command.

Clifm and terminal emulators

Despite the above, however, it is important to bear in mind that listing speed does not only depend on the program's code and enabled features, but also on the terminal's rendering speed.1 Old, basic terminal emulators like Xterm, Aterm, and the kernel built-in console are quite slow compared to more modern ones like Urxvt, Lxterminal, ST, or Alacritty, to name just a few.2

1 On this topic, see this excellent article written by Anarcat. See also https://stackoverflow.com/questions/3857052/why-is-printing-to-stdout-so-slow-can-it-be-sped-up.

2 If using Xterm, setting the fastScroll resource to true in your ~/.Xresources file produces a quite decent performance boost in terms of rendering speed: XTerm*fastScroll: true. Even thus, nonetheless, it is far behind modern terminal emulators, specially when it comes to large directories.

Clone this wiki locally