Thanks for the bug report! It's a bit difficult to guess what causes the slow startup on your system, and if it has anything to do with Dolphin itself, or with some KDE libraries that Dolphin uses. Is Dolphin really the only application that is affected? What about other KDE applications, such as KWrite? Do you notice similar delays if you open the application or if you open the "Open File" dialog?

I don't think it's related to my system (i3 2100, SSD Samsung 840 250Gb, 4Gb) because I installed Netrunner (Kubuntu derivative) on some other computers and Dolphin always seems a little bit "sluggish" when you open it. I am not the only one as you can see here (http://forums.netrunner.com/showthread.php?tid=16644). I also noticed similar delays when I open the "Open File" dialog.

Of course some other application can take longer to open but it's because there are "heavy", like gimp. If I try Kate and Sublime text, they take about the same to open, 0.5s give or take.

If I compare Dolphin to others file browsers it's the slowest, it take about 1s to open. Thunar for exemple open really instantly.

1s is a short period of time but when you click on something and nothing happen for a whole second it's seems slow, especially with a SSD. Try to install Thunar to compare. It will be awesome if we can achieve this speed ;)

Here are some exemple of the "slow" start :

https://youtu.be/vWsJ4PQhH4s?t=3m58s
https://youtu.be/1I93Q-1SwUY?t=10s

(In reply to jeremy9856 from comment #2)
> I also noticed
> similar delays when I open the "Open File" dialog.

In that case, the slowness is probably not caused by Dolphin itself, but by some of the libraries that Dolphin and the file dialog use.

BTW, does it start faster if you hide the "Places" panel?

> 1s is a short period of time but when you click on something and nothing
> happen for a whole second it's seems slow, especially with a SSD. Try to
> install Thunar to compare. It will be awesome if we can achieve this speed ;)

I cannot reproduce a 1 second delay here, but I agree that any improvement of the startup speed would be welcome. However, finding out what the reason for the slow startup that you and some others see might not be straightforward, and it could very well be that the reason is in the libraries that Dolphin and the file dialog use, such that nothing can be done in Dolphin itself to fix it.

Note: It has been proposed recently to make all Dolphin windows share a single process ( https://git.reviewboard.kde.org/r/123921/ ). If this is implemented, then at least opening a another Dolphin window should be much faster if one window is open already.

Created attachment 92998 [details]
Debug performance issues with strace

Dolphin doesn't start faster if I hide the "Places" panel.

I think that Dolphin windows share a single process is a good thing, at least for the speed when you open several windows.

i recently read this article "Debug performance issues with strace" :
https://bryanquigley.com/uncategorized/debug-performance-issues-with-strace

So I tried it with Dolphin. Does it help ?

An other user report the same behavior

https://forum.kde.org/viewtopic.php?f=223&t=126482

(In reply to jeremy9856 from comment #5)
> So I tried it with Dolphin. Does it help ?

Thanks. I only had a quick look, but I could not see any single obvious issue that takes a lot of time. There are lots of accesses to various files, which together cause a rather long delay, but the vast majority of these file accesses are not done by Dolphin at all, but by various libraries. There is probably a lot of room for optimizations, but I'm afraid that little can be done inside Dolphin about this. This must be done in the libraries (and then all KDE applications will benefit).

Ok so what next ?
You check that with the concerned people or you want me to do some other bug report at the right place or something else ?

(In reply to jeremy9856 from comment #8)
> Ok so what next ?
> You check that with the concerned people or you want me to do some other bug
> report at the right place or something else ?

I don't know, sorry. Figuring out what code is responsible (and thus who the concerned people are and what the right product for a report is) from the traces will take some effort and time, which I currently don't have, but maybe someone else who has an idea will read this report.

Ok I understand. It's not a serious problem but if it can be fixed it will be a great improvement.

Just a little video to show you how fast is Nautilus to start

https://www.youtube.com/watch?v=CtBjaBz1u10

Hi. I also started suffering from this issue following an upgrade last week to kdelibs-4.14.7-4.fc21.x86_64 (I'm running Fedora 21).

I can tell that this is not dolphin-related, but is widespread to any application that needs/uses the kde "file open" dialog facility whenever that dialog is opened (dolhpin, kate, kwrite, kile, etc, even konsole, if you invoke "save output as"). This is crippling because the bulk of my productivity applications are native kde tools and saving or opening anything stalls my system nearly every time for 30-60 seconds.

It seems to be caused by endless calls to a "fd 6", which is an existing socket. Here is a quick summary of what happens running dolphin and kwrite:

=== Dolphin ===

$ strace kwrite 2>&1 | grep -i "temporarily unavailable" > strace-dolphin.log

$ grep -c "recvmsg(6.*temporarily unav.*"  strace-dolphin.log
1063

$ ls -l /proc/21982/exe
lrwxrwxrwx. 1 vpereira 0 Jun 16 18:21 /proc/21982/exe -> /usr/bin/dolphin

$ ls -l /proc/21982/fd/6
lrwx------. 1 vpereira 64 Jun 16 18:21 /proc/21982/fd/6 -> socket:[613025]

=== kwrite ===

$ strace kwrite 2>&1 | grep -i "temporarily unavailable" > strace-kwrite.log

$ grep -c "recvmsg(6.*temporarily unav.*"  strace-kwrite.log
4064

$ pgrep kwrite
22097 kwrite

$ ls -l /proc/22097/fd/6
lrwx------. 1 vpereira users 64 Jun 16 18:29 /proc/22097/fd/6 -> socket:[615328]

$  sudo netstat -apn | grep 615328
unix  3      [ ]         STREAM     CONNECTED     615328   22097/kwrite

===

Now, if I login with (what I think is a) clean kde configuration by removing (outside of kde)
  ~/.kde 
  /tmp/kde-vpereira/ 
  /var/tmp/kdecache-vpereira/ 
  /run/user/1000/ksocket-vpereira

the problem persists! It does go away if I login as a clean new user, though (meaning an empty $HOME). 

If someone can help debug or understand this further it would be much appreciated!

(In reply to Vitor M. Pereira from comment #12)
> This is crippling because the bulk of my
> productivity applications are native kde tools and saving or opening
> anything stalls my system nearly every time for 30-60 seconds.

If the freeze takes that long, then something is seriously wrong, and getting a backtrace is the best way to find out what it is. Please see https://community.kde.org/Dolphin/FAQ/Freeze for details and file a new bug report, because this issue is different from the one that has been reported here. Thanks for your help!

(In reply to jeremy9856 from comment #11)
> Just a little video to show you how fast is Nautilus to start
> 
> https://www.youtube.com/watch?v=CtBjaBz1u10

I'm afraid that videos are not very useful for debugging performance issues. I have no idea how Nautilus' internals work - maybe new windows share a process with existing windows (as I said, this has been proposed for future Dolphin versions), maybe they even preload a Nautilus process to make startup faster or maybe it is something else altogether. Apart from that, I agree that getting rid of some of the expensive things that apparently happen when starting Dolphin (and probably other KDE apps that deal with files) would be extremely desirable, but as I said, this can only be done by analyzing carefully not only the strace logs, but especially which libraries are responsible for these expensive system calls and what exactly happens inside these libraries that Dolphin uses. Someone who has the necessary time, motivation and skills must sit down and do it. New videos do not help - sorry about that.

I know the videos doesn't help but it's just to show the difference in startup speed.
Maybe it can motivate someone who has the necessary time, motivation and skills ;)

(In reply to Frank Reininghaus from comment #13)

Thank you, Frank, for the quick reaction and your suggestion. Following it, it seems clear now that this is related to KFilePlaces somehow. I opened bug 349290 and posted a few backtraces there. 

If there is something else that I can contribute to help diagnose this, kindly let me know.

(In reply to Frank Reininghaus from comment #13)

A quick follow-up to mention that I can now reproducibly trace my problem down to dolphin generating a corrupted 

  ~/.kde/share/apps/kfileplaces/bookmarks.xml

when a change is made to the contents or ordering of folders in the "Places" panel. Please refer to my comments in bug 349290.

I checked the delay when I open the "Open File" dialog and it is at least 2 times lower than I open Dolphin. About 0.4s vs Dolphin 1s.

I don't know but maybe that mean that is something that can be improved in Dolphin ?

Do you think the switch to KF5 will improve the load time ?

(In reply to jeremy9856 from comment #17)
> I checked the delay when I open the "Open File" dialog and it is at least 2
> times lower than I open Dolphin. About 0.4s vs Dolphin 1s.

Considering that the application that you use the "File" dialog with has already loaded some kdelibs or KF5 libraries that are used by the file dialog, and Dolphin has to load everything at startup, this is probably the expected behavior.

I have the same problem with startup now hitting 1minute.  This also applies to qt file-dialogs .

This is making my machine unworkable.  I am running Fedora 21 for quite some time but this only seems to have started in the last week.

I have cleared all config for dolphin with no change.

I have logged an strace.  It appears to be caught in a sequence trying to get information about a particular logical volume.  The trace is full of 'device is temporarily 

This repeats in the strace file 42000 times while dolphin is 'hung'. 
dm-4 is a mounted lv.  I have run a force fsck on it with no problems.  It is only 77% used.  Not used for any general usage.

I can attach the full strace if needed, at 108Mb.  

---strace cut---  Not sure if this is the exact loop start and finish of the loop ...


open("/etc/udev/udev.conf", O_RDONLY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=49, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff94e619000
read(18, "# see udev.conf(5) for details\n\n"..., 4096) = 49
read(18, "", 4096)                      = 0
close(18)                               = 0
munmap(0x7ff94e619000, 4096)            = 0
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
readlink("/sys/dev/block/253:4", "../../devices/virtual/block/dm-4", 1024) = 32
stat("/sys/devices/virtual/block/dm-4/uevent", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
open("/sys/devices/virtual/block/dm-4/uevent", O_RDONLY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff94e619000
read(18, "MAJOR=253\nMINOR=4\nDEVNAME=dm-4\nD"..., 4096) = 44
read(18, "", 4096)                      = 0
close(18)                               = 0
munmap(0x7ff94e619000, 4096)            = 0
readlink("/sys/devices/virtual/block/dm-4/subsystem", "../../../../class/block", 1024) = 23
open("/run/udev/data/b253:4", O_RDONLY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=738, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff94e619000
read(18, "S:disk/by-id/dm-name-vg_hpmodell"..., 4096) = 738
read(18, "", 4096)                      = 0
close(18)                               = 0
munmap(0x7ff94e619000, 4096)            = 0
sendmsg(15, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\234\310\0\0\223\0\0\0\1\1o\0&\0\0\0/org/fre"..., 168}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 168
poll([{fd=15, events=POLLIN}], 1, 25000) = 1 ([{fd=15, revents=POLLIN}])
recvmsg(15, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\v\2\0\0\353\342\1\0.\0\0\0\10\1g\0\1s\0\0\5\1u\0\234\310\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 587
recvmsg(15, 0x7ffe2dec7320, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
open("/etc/udev/udev.conf", O_RDONLY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=49, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff94e619000

*** Bug 384501 has been marked as a duplicate of this bug. ***

Dolphin is "slow" to launch >= 1000ms on an SSD.
So I tried to breakdown the pain points.

Tested by adding: qCDebug(DolphinDebug) << "mark1";
between statements and running: dolphin 2>&1 | ts "[%.S]"

* [main.cpp] new QApplication() takes 50ms
* [dolphinmainwindow.cpp] new DolphinViewActionHandler() is pretty slow. It calls DolphinViewActionHandler::createActions() in the constructor, which takes 140ms.
    * [dolphinviewactionhandler.cpp] The bulk of which is taken up by the "#ifdef HAVE_BALOO    Baloo::IndexerConfig config;" statement (probably file IO) which takes 134ms.
* [dolphinmainwindow.cpp] setupDockWidgets takes 100ms
* [main.cpp] mainWindow->openDirectories takes 250ms
* [main.cpp] DolphinMainWindow::show() takes 150ms

Hello,
Just went through this 'lag' on a clean Opensuse Leap 42.3 install.
- Happens on dolphin startup and Open/Save boxes in any KDE app
- not having such a lag on another hardware with similar software.
So went into personal notes (from years ago) and found something relevant.


Symptom : On laptops, some user actions (open dolph, right click on dolphin folder,...) produce a noticeable delay before UI responds.

Fact : Kdirlister spends significant time enumerating /sys (sub)folders

Fact : Unmounting SYSFS suppresses the lag (but breaks pretty much anything else).

Fact : Unloading 'battery' kernel module suppresses the lag.

Action : /etc/modprobe.d/99-local.conf
  options battery cache_time=60000

Question :
Why does KDE (core / framework / ...) have to "actively" (and "blockingly") query battery status, and probably other hardware stuff, on user actions ?
Could this be instead managed by a background KDE cache ?
Not a bug, but a serious UI responsiveness issue.

I experience the same - Dolphin needs 1-2s to load on my 4Ghz Quad Core equipped with an SSD - and this is not caused by I/O, as subsequent starts are also slow.

Other file managers open almost instantly, I hope Dolphin can be brought to the same speed. Unbelievable Dolphin was once promoted as light-weight alternative to konqueror,

Not sure if I have the same issue:

When I first time launch Dolphin, it is slow (about 3 seconds). After that, launching Dolphin will be very fast (less than a second).

I have NVME SSD, Core i7 8550U, 32GB RAM.

Guo, you might see the same Futex deadlock that is described at bug 409574. An strace log could confirm.

I also confirm this. Even on a PCIe SSD (on which apps seem to start much faster than on SATA), Dolphin occasionally takes around 3 seconds to launch. On SATA, it occasionally took up to 10 seconds. This was always random; usually, it launched fairly instantly.

Can confirm this happens on an NVME SSD on Arch too. Had this issue on Pop!OS too. Clean install of Arch and it still happens. Slowdown is quite random, it starts instantly sometimes, but sometimes it takes as much as 10 seconds.

In my system, this issue seems disappeared for some time after upgrading. How about others?

Operating System: openSUSE Tumbleweed 20191009
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.13.1
Kernel Version: 5.3.4-1-default
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 31.1 GiB

*** Bug 416937 has been marked as a duplicate of this bug. ***

Info from Bug 416937 that might be appropriate her:

    At times Dolphin is very slow to start (and then to navigate). Whether launched from a link or the command line, it takes about a minute to start properly. The majority of the time it starts within a couple of seconds, then for no discernable reason it takes 30 seconds for Dolphin to appear on screen and another 25/30 seconds for the panel to be populated. This behaviour persists for some minutes and then goes back to normal. If you log out and back in again, the problem goes away. 

    No fixed or repeatable way of reproducing this. 

    Tested in a KVM guest under a 'test' username with a small number of user files. No mounts of other filesystems, local or remote. No tags defined. In this configuration, actively trying to provoke the bug, it happens one or twice a day.

    There's a screen recording and strace capture attached to Bug 416937

*** This bug has been confirmed by popular vote. ***