The Dolphin process will temporarily freeze and become fully unresponsive when opening large directories with huge amounts of files. For instance: Whenever entering a folder with about 100.000 images, Dolphin stops working for roughly 8 seconds. This time is even longer when accessing the directory for the first time after the machine has booted, likely due to the kernel also having to generate its page caches. While not a major issue, this is an annoyance and looks very bad to the end user. The desired functionality is for the user to remain able to use the menus, or resize the window without the desktop compositor leaving ugly trails inside (since the window is not redrawn either while busy). Ideally there should be a spinning circle somewhere in the interface, indicating that the contents of the directory are being loaded in the background. This effect is most likely caused by the Dolphin process going into disk sleep mode (I/O scheduling) while reading the data of the directory. As such this may require deeper changes to how Linux accesses partitions and works with files in order to properly solve. One thing KDE can and should do in the meantime, is separating the process responsible for reading files from the process of the application itself: From what I remember this should already be the case with some software, which lets a process called file.so (or another process with a similar name) handle the drive I/O for it then send the data once ready. Does KDE use a similar approach, and if not could and should it? Note that this issue may affect multiple pieces of KDE software, particularly those that work with large quantities of files from the hard drive... for instance Gwenview when it accesses large amounts of images at once. As Dolphin is what I'm most consistently and reliably noticing this problem with, I reported this as a Dolphin issue.
Does it happen only with images? Can you start dolphin from gdb a get a backtrace when it freezes? And to answer your question, yes Dolphin already handles the filesystem out of process (thanks to the file kio-slave).
(In reply to Elvis Angelaccio from comment #1) Just tried entering a directory with roughly 50.000 text files. Same issue: Dolphin is frozen for about 4 seconds upon entering the folder. I should also note that the freeze occurs the same way for refreshing: Whenever I press F5 to refresh, Dolphin stops working for the exact same amount of time as when I enter it. I thought GDB only works when a process permanently freezes. This is a temporary freeze and likely not due to a crash, so I'm not sure if it will capture anything useful. I might try this test tomorrow. It's surprising to hear that this shouldn't be happening as it seemed like it's by design. If a different process is doing the reading then it indeed shouldn't have this effect. I can only suspect something having to do with disk I/O. For reference, I use openSUSE Tumbleweed x64 and my partitions are all ext4.
I decided to look at the Dolphin process in KSysGuard while it's loading those directories. Surprisingly it doesn't go into "disk sleep" mode like I thought: It uses between 10% and 90& CPU until the directory finishes loading, after which it stops using any CPU and returns to normal. Could this be due to sorting? I sort the directory by name though, and even if I disable natural sorting it still does it. I noticed the times are much longer when I sort by date instead, so perhaps this is related. If I run the command "ls" inside the directory from a bash console, it finishes listing everything in less than two seconds. Dolphin is clearly doing something that's causing it to take longer than normal.
I'm going to mark this resolved as I haven't seen it happen in a long time. Dolphin still takes a bit to open large directories, however its process no longer downright freezes while doing this, files and folders appear gradually while the program can still be used during that time.