Dolphin: Loading of large directories very slow after update

Support KDE Plasma
1

As of [Stable Update] 2023-10-13 large directories take a ridiculous amount of time to load in Dolphin. A folder with over 65.000 images would previously take some 15 seconds to load, now it’s over 5 minutes. During this time I see 100% of one CPU core being used, however I can’t find a root or user process doing it and it’s not the Dolphin application itself… my hard drive keeps being read at a rate of 3 MB/s.

This only happens once per directory after boot, after a directory finishes showing up it will load at normal speed until you reboot. I tried disabling previews but that doesn’t seem to affect the issue. It’s definitely not a problem with my drive and was introduced by the last update, other operations such as using the ls command are just as fast only Dolphin appears to be affected.

2

https://bugs.kde.org/show_bug.cgi?id=442106

I found this thread and bug report which describe my issue. However they appear to be from 2021: Was the problem reintroduced somehow in Dolphin 23.08.1?

3

Please provide the output of:

cat /etc/fstab

It is possible that the following post is relevant to your issue:

4 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=eabe1a99-1671-4b1c-9817-d5855ba9cea3 /         ext4  defaults         0 1
UUID=17A0-DD48                            /boot/efi vfat  defaults         0 2
UUID=bf55ce0e-d6cc-49fd-ba02-d14886a418bd /home     ext4  defaults,nofail  0 2
UUID=e7fc4aee-f26a-4880-8e6a-628abcd50514 /archive  ext4  defaults,nofail  0 2
tmpfs                                     /tmp      tmpfs defaults,noatime 0 0

/archive is where affected directories I can check are located, it’s a HDD whereas the others are SSD. I generally don’t modify it as to not break things, if it’s suspected to help I can try… I wonder if it can be the same issue as that bug, that one was marked as fixed two years ago.

5

Are you saying that only directories on that drive are affected? (Just to clarify) – No slow-loading folders anywhere else?

That’s less likely if only a specific disk is affected. Is it an external disk?

You could comment that disk in fstab, and try mounting it manually for a while, to see if that makes a difference.

1 Like
6

I meant that I can’t check the others as I don’t have such large directories on them: It’s only my HDD that has a few folders with so many images to clearly produce the slowdown.

Or actually I just realized I can: My home folder which is an SSD has something similar in ~/.cache/thumbnails/large where it caches thumbnails, nearly 50.000 images in one place. I opened that up in Dolphin and it didn’t seem to be as slow! It’s possible the problem affects only my HDD.

sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   26572 MB in  1.99 seconds = 13326.37 MB/sec
 Timing buffered disk reads: 568 MB in  3.00 seconds = 189.06 MB/sec

Using this quick benchmark command I had noted down, it gives me normal results for a SATA3 drive… the link speed confirms is connected at 6 Gb/s. When Dolphin is stuck loading I instead a see 3 MB/s drive read, it’s like Dolphin alone has a limited disk read speed.

7

It may be worthwhile running fsck on that drive in case there is any filesystem corruption.

1 Like
8

If you are using Baloo indexing, try disabling it for that particular drive in the System Settings. :point_down:

Baloo Settings
Baloo Settings1920×1080 126 KB

Add the mountpoint to the list and then set it to Not indexed.

9

Is it possible that you may skipped a few updates? Because i experience slow load times in dolphin since around 2-3month.

10

Have you tried the approach above, i.e. disabling indexing by Baloo for that drive/folder?

11

I can dig it. :cat2:

1 Like
12

Already did a boot with fsck.mode=force fsck.repair=yes which I do periodically: I left it run on the HDD till it finished then rebooted, no change.

Baloo is already disabled in that directory. It still has huge issues indexing large folders so I did that a while ago to avoid excessive resource and hard drive usage till it someday improves.

Definitely no incomplete update, sudo pacman -Syu confirms there’s nothing to do.

13

My experience is even worse than yours; I’m on the unstable branch and I saw Dolphin’s performance slowly degrading in the last 5 months.

In my fstab I have three nfs mounts declared (they refer to some NAS shares). If the NAS is not started / available, then launching Dolphin results in having a non-responsive and useless window - no matter how long I waited, Dolphin was not becoming usable, so I had to kill it (waited more than 30 min after freshly restarting the PC).
I clearly remember this not being the case up until March - April this year. Then, not having the NAS available resulted just in empty folders at the mount point - that was the normal behavior - and no delays at all.

These are the options I have for each nfs mount; they were not changed since I installed Manjaro 15 months ago.

noatime,nofail,users,x-systemd.automount,x-systemd.after=network-online.target,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0

What is a clear indication that something is really wrong with the latest updates in KDE is that, while Dolphin is very slow and sluggish to open a large folder (or becomes unusable if the NAS is not available), opening a similar folder from a GTK based application (which does not use KDE’s libraries) is without any visible delay.

My guess is that there were other changes that where not completely undone by the patch in the KDE bug #442106.
edit: Actually it is bug #454722 which does not seem to get enough attention.

The file search indexation is disabled on my PC.

edit 2: 2023-10-20 - potential solution

I was sifting through the KDE bugs and I found a gem: #451876 - bloated user-places.xbel causes poor performing dolphin, file open dialogs, gvenview, krusader and other apps .
I immediately tested how that might work for me - and, surprise, I got from a very lazy/sluggish Dolphin to a speedy one.

What I did:

  1. I went to ~/.local/share/ folder and renamed user-places.xbel to something else (user-places.xbel.ORIG)
  2. I started Dolphin and, behold, it was now fast as the first day.
  3. A new user-places.xbel file had been generated, but it had the default options.
  4. I compared the new file user-places.xbel with the old file (user-places.xbel.ORIG) and I picked the shortcuts that were really useful for me and copied them in the new user-places.xbel - being careful to not break the XML structure.

I enjoy now again using Dolphin !

The explanation: a lot of cruft added by/for Docker and KDE Connect. My original user-places.xbel file was not even that big, but there was some reference there that gave a lot of trouble to Dolphin.

edit 3: 2023-10-24 - final thoughts

After cleaning the user-places.xbel file, everything is fine while the nfs mounts are available, but as soon as the NAS is not available, even after a fresh start of the system, Dolphin will take its time when navigating to any local folder.
So, there are clearly two different reasons for slow Dolphin:

  • having a cluttered user-places.xbel #451876
  • having nfs mounts that are not available #454722

Hoping that this might help …

2 Likes
14

After months of struggling with this issue it seems that today, after installing the latest Manjaro stable snapshot, this issue finally ceased: I opened large directories I use preemptively to load them after login, and noticed that instead of 10 minutes of slow loading their contents appeared in 5 seconds. I’d like to take some time to ensure it’s permanent and the slowness never happens again before concluding it’s solved for good but for now it appears to be.

I wonder what in KDE has been causing it all this time, or whether it was a different system component doing it: The only obvious change is an upgrade from Kernel 6.9.0 to 6.9.2, if it was the kernel the fix happened in 6.9.1 or 6.9.2. The switch from Plasma 5 to 6 was a few weeks back but even then the issue continued until today.