Plasma Emojier Too Slow, Episode IV

One of my biggest annoyances with NixOS on desktop these days is that apps are too darn slow to start. Not 2 seconds slow (that would be unusable), but ballpark of 0.5 seconds slow, between me hitting Enter to open an App, and GUI actually showing up. So I am on a make-shift crusade to fix it file & follow the relevant issues. And plasma-emojier is my trusty companion.

In Episode I, it was discovered that the bash script wrapping emojier is accidentally quadratic. As they say, optimize big-O first, so we swapped in C for bash to get some decent improvement.

In Episode II, a discrepancy was observed between starting emojier from the CLI and using a global shortcut. This was due to some extra unnecessary intermediate process on the Plasma side, which was since fixed in Port app launching to ApplicationLauncherJob (!3) · Merge requests · Plasma / KGlobalAccel Daemon · GitLab.

In Episode III, I got significant cold start speed up by disabling my nvidia GPU. I used nixos-hardware to turn it off, and nvtop to confirm that it is, in fact, turned off. Which wasn’t enough — I also had to completely remove hardware.nvidia, otherwise the emojier tried to poke the device with disastrous (for start up times) consequences:

openat(AT_FDCWD, "/sys/bus/pci/devices/0000:00:0d.0/config", O_RDONLY) = 15 <0.000014>
read(15, "\206\200\36F\6\4\220\2\0020\3\f\20\0\200\0\4\0&\5b\0\0\0\0\0\0\0\0\0\0\0"..., 48) = 48 <0.173553>
openat(AT_FDCWD, "/sys/bus/pci/devices/0000:00:01.0/config", O_RDONLY) = 15 <0.000090>
read(15, "\206\200\rF\7\5\20\0\2\0\4\6\20\0\201\0\0\0\0\0\0\0\0\0\0\1\1\0@@\0 "..., 48) = 48 <0.165022>

Now, the above is probably a bug — my dGPU is powered off, and all the rendering is done by intel. There’s no reason software should be poking at that pci bus at all. I haven’t filed a bug about that, as I have no idea which layer of software stack is responsible for doing those reads :frowning:

But, anyway, completely jettisoning nvidia worked for me :slight_smile:

So now we come to Episode IV, this installment.

Emojier is … well, it isn’t drunken slug slow anymore:

λ t plasma-emojier --version
plasma.emojier 5.27.10

real 191.44ms
cpu  179.92ms (130.39ms user + 49.53ms sys)
rss  101.17mb

But fast this clearly isn’t.

Here’s what strace has to say about this:

λ strace -w -c plasma-emojier --version
plasma.emojier 5.27.10
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- -------------------
 60.64    0.145800           9     14865     14096 statx
  6.61    0.015888           9      1640      1549 readlink
  5.90    0.014175          11      1240       923 openat
  5.32    0.012794          17       743           mmap

I think this is us, NixOS. We have some ridiculously long search paths which emojier tries in order to load some things:

newfstatat(AT_FDCWD, "/nix/store/ga17mlfsss2fndyvp2s1m0s2rx2b4i9s-libX11-1.8.7/lib/", {st_mode=S_IFDIR|0555, st_size=4096, ...}, 0) = 0 <0.000010>
openat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/glibc-hwcaps/x86-64-v3/libKF5ConfigGui.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000011>
newfstatat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/glibc-hwcaps/x86-64-v3/", 0x7ffe3d51b190, 0) = -1 ENOENT (No such file or directory) <0.000009>
openat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/glibc-hwcaps/x86-64-v2/libKF5ConfigGui.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000010>
newfstatat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/glibc-hwcaps/x86-64-v2/", 0x7ffe3d51b190, 0) = -1 ENOENT (No such file or directory) <0.000009>
openat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/libKF5ConfigGui.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000010>
newfstatat(AT_FDCWD, "/nix/store/znk677nrcipl9jrnwjfzfx65wdmh77iy-qtbase-5.15.12/lib/", {st_mode=S_IFDIR|0555, st_size=12288, ...}, 0) = 0 <0.000010>
openat(AT_FDCWD, "/nix/store/56rvf22j5bn7jpmbmd2ia88mkxpfc8pm-ki18n-5.114.0/lib/glibc-hwcaps/x86-64-v3/libKF5ConfigGui.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000010>
newfstatat(AT_FDCWD, "/nix/store/56rvf22j5bn7jpmbmd2ia88mkxpfc8pm-ki18n-5.114.0/lib/glibc-hwcaps/x86-64-v3/", 0x7ffe3d51b190, 0) = -1 ENOENT (No such file or directory) <0.000009>
openat(AT_FDCWD, "/nix/store/56rvf22j5bn7jpmbmd2ia88mkxpfc8pm-ki18n-5.114.0/lib/glibc-hwcaps/x86-64-v2/libKF5ConfigGui.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000009>

... and a thousand futile attempts more like this ...

Is there anything we can do here? Or perhaps there’s something KDE folks can do to make NixOS and plasma play nicer together?

4 Likes

Episode V: The real culprit!

tl;dr: Maybe things will be solved with plasma 6.0, they were solved on the kde2nix repo.

Long read:

Like I commented also on the Quadratic thread, I also have struggled with this. On plasma5, some apps take much more than on arch, for example. Dolphin for example, is one, while konsole is not so much affected.

After lots and lots of benchmarks and searching and testing stuff (like preload, but didnt solved it), etc, I stumbled in a bug report (which google now fails to find) which gave me a clue about what to do:

Remove extra huge trillion lines XDG_DATA_DIRS and other XDG’s

So I found out that almost all can be removed, because nix apps already include the PATHs in the “what used to be quadratic scripts”, and everything started starting :slight_smile: fast!

The good news, is that testing plasma 6.0 on the kde2nix repo, the XDG_DATA_DIRS were not so huge, and it was noticeable faster! So, maybe when integrated into nixos nixpkgs, it will keep being that way!

1 Like

I just read the thread about the hugh amount of XDG_DATA_DIRs and also noticed that there are at least some derivations up to 3 times on my env var, maybe we can already fix that and possibly it already helps a bit, i might dig into it for my setup and report back when i find something noticable

2 Likes

Huh, yeah this does seem to happen:


11:43:17|~/tmp
λ echo $XDG_DATA_DIRS | tr ':' '\n' | wc -l
187

11:43:29|~/tmp
λ echo $XDG_DATA_DIRS | tr ':' '\n' | sort | uniq | wc -l
97

would be great to dig into the source of duplication!

1 Like