Bug 422306

I am seeing the same issue. I commented on it in the other bug report # 393977.

This old post sounds similar to my issue:
https://forum.kde.org/viewtopic.php?t=119733

I checked and Gwenview is also slow to open (like in that link)

also in Dolphin, File menu | New Window is just as slow as initially opening Dolphin.

> Dolphin, as well as KDE file dialogs in all KDE applications, open very slowly. It takes several seconds for the file-open dialog to display in Kate or any other application. Also, it takes several seconds for Dolphin to display any window content on first opening. 

I don't reproduce on my systems and given how critical it would be, I expect this bug to relate to your systems state or settings.
I assume you are running dolphin latest stable version 20.04.

That being said the fact that Dolphin and file/Open dialogs are concerned point to their underlying dir listing common component KIO's KCoreDirLister.

We need more information to track down the bug origin.

Given the problem should be obvious using a flamegraph tool such as https://github.com/KDAB/hotspot
If you could use this tool to obtain a perf trace of dolphin for instance and share the resulting perf file.
It would need the debug symbols still to be useful and pay attention to its caveat https://github.com/KDAB/hotspot#recording-with-perf-without-super-user-rights . You can find how to get debug symbols on your system at https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

But a few question can get a long way already:

How many files or folders does your home folder contain ?
Does this happen when dolphin or the kde file dialog open any directory at launch ?
Do you have many symlinks in your home ?
Do you have network drives ? If yes how many ?
Is it reproducible under Wayland ?

MountainX: Do you use Arch as well ? With same version ?

> the problem should be obvious using a flamegraph tool such as https://github.com/KDAB/hotspot

This looks interesting. A lot of it is over my head, but I am willing to give it a try.

>  pay attention to its caveat (super user rights)

I don't understand the steps at https://github.com/KDAB/hotspot#recording-with-perf-without-super-user-rights

Here are some questions I have:

>>  This is achieved by applying these steps, bundled into a script that is run via kdesudo or kdesu. 

Do I run `kdesudo elevate_perf_privileges.sh` before launching the HotSpot tool?

> Using Hotspot: First of all, record some data with perf. To get backtraces, you will need to enable the dwarf callgraph mode: 
>> perf record --call-graph dwarf <your application>

What are the exact steps I would need to do? Is this correct?
1. kdesudo elevate_perf_privileges.sh
2. perf record --call-graph dwarf dolphin
3. open the HotSpot GUI?

> It would need the debug symbols still to be useful

I don't think I will be able to compile packages from source. Is it still worth doing any of this? 

I will proceed even without debug symbols if this will allow me to see if Dolphin is being slowed by a configuration in my user profile (such as some *rc file) or by something like a large list of recently used files, etc. If the information will be granular enough to allow me to learn something, I will proceed to investigate even without being able to compile the executable with debug symbols. On the other hand, if it is a complete waste of my time, let me know and we'll have to hope somebody with more skills can provide the debug info.

> How many files or folders does your home folder contain?
183 at level 1 using 'wc -l'
Setting Dolphin to open at another location doesn't affect the issue.

> Does this happen when dolphin or the kde file dialog open any directory at launch ?

Yes.

> Do you have many symlinks in your home ?

No.

> Do you have network drives ? If yes how many ?

Yes. Around 10 NFS mounts.

> Is it reproducible under Wayland ?

I can't answer that.

> Do you use Arch as well ? With same version ?

Yes, I am running Arch. My current Dolphin version is 20.04.1.

Created attachment 128985 [details]
Hotspot top down

Attachment 1 [details] of 2.

Is it normal for Dolphin's startup processes to be dominated by QImageReader::read()? This perf data was recorded just for opening Dolphin. No other activity occurred.

I use custom images for several dozen folder icons. Could that cause a performance issue? I also use my own icons for all the items in my Places bookmarks.

Created attachment 128986 [details]
Hotspot bottom up

Attachment 2 [details] of 2.

Is this normal for Dolphin startup?

(In reply to MountainX from comment #5)
> Created attachment 128985 [details]
> Hotspot top down
> 
> Attachment 1 [details] of 2.
> 
> Is it normal for Dolphin's startup processes to be dominated by
> QImageReader::read()? This perf data was recorded just for opening Dolphin.
> No other activity occurred.
> 
> I use custom images for several dozen folder icons. Could that cause a
> performance issue? I also use my own icons for all the items in my Places
> bookmarks.

That's the kind of local setting that most users don't use and that makes your system apart, and might be an explanation for the bug.
Especially combined with your 10 NFS mounts.

I need the perf output of hotspot.

> I need the perf output of hotspot.

I don't have the debug symbols. Is the perf output of hotspot still of use to you? If so, how do I get it? I'm not seeing an output option in hotspot commands/menus. 

Do you mean the raw perf.data file I recorded with `perf record`? I used `perf record --call-graph lbr dolphin`. Is that sufficient?

Sorry, all this is new to me.

(In reply to MountainX from comment #8)
> > I need the perf output of hotspot.
> 
> I don't have the debug symbols. Is the perf output of hotspot still of use
> to you?

I meant the perf command output (hotspot is just a visualization tool that can start perf too).

> If so, how do I get it? I'm not seeing an output option in hotspot
> commands/menus. 
> 
> Do you mean the raw perf.data file I recorded with `perf record`? 

Yes

> I used `perf record --call-graph lbr dolphin`. Is that sufficient?

Share it still, if it fits as an attachment that is.

> 
> Sorry, all this is new to me.

No worries, it is not an easy task to ask.

But since we have a lead (per-directory icon + NFS mounts), that' may not be necessary to got further with this tool.
Although debugging with debug symbols is the fastest way to debug.

I was able to do further testing. I found some interesting things.

1. This issue is affected greatly by ~/.local/share/user-places.xbel. Deleting that file causes Dolphin to create a new one that contains only local storage devices and remote mounts (such as NFS) that are listed in /etc/fstab. This seems to be the minimal user-places.xbel that is possible in Dolphin.

Comparing the minimal user-places.xbel to a "large" version with 30 user bookmarks, half of which have a customized icon, I see a difference in Dolphin startup time of over 600%. 

With the "large" user-places.xbel my Dolphin startup time is 2-3 seconds. KDE file dialogs are also similarly slow to come up.

The the minimal version of user-places.xbel, KDE file dialogs open without any apparent delay and Dolphin has a minimal delay (I estimate half a second).

The approximate half second delay may be due to the fact that my minimal version includes 10 NFS mounts.

I create intermediate versions, each with varying amounts of my own bookmarks in Places (which increases the items in user-places.xbel compared to the minimal). With each increase, there is a corresponding longer startup time for Dolphin and a corresponding longer time for KDE file dialogs to come up. 

I had seen this behavior before, but now we have verified it in a more rigorous way. I am highly confident that user-places.xbel can have a strong negative impact on Dolphin start up times (and KDE file dialogs). The relationship is 100% causal and 100% reproducible.

2. I believe there may be another factor involved as well. I have access to another computer running Arch Linux and the same versions of KDE (latest). A colleague and I tested similar configurations of user-places.xbel. The second computer does not show as steep a decline in Dolphin performance with increasing entries in user-places.xbel. The effect is still present, but much more moderate. I will continue experimenting to see if I can find this missing factor. I have some guesses:

- Is it the icons used for folders? Maybe.
- Is it the NFS mounts? No. We set up both computers with the same NFS mounts in /etc/fstab.
- Is it the Dolphin startup directory? No.
- Is it a hardware difference (such as CPU, RAM, SSD or GPU) between the test computers? No.
- Is it recently-used.xbel? Apparently no (with simple testing). 

3. There are no obvious differences in the straces or perf reports between the two computers. Obviously, we do not have debug symbols and we do not know how to do debugging or perf testing in great detail. One computer has much better Dolphin startup time and KDE file dialog performance than the other, but they do not have overall different performance on benchmarks or apps. (The slightly faster machine is the one with slower Dolphin & file dialogs).

Questions: 

1. We would like to copy versions of user-places.xbel from one computer to another for testing. How can we handle the unique ID in each entry in this file? What are those ID's matched against? Example:

<ID>1580172204/1</ID>

2. Is there a way I can test Dolphin without any entries in user-places.xbel (without altering /etc/fstab)?

3. what other files, besides user-places.xbel and recently-used.xbel, could impact Dolphin startup times? Should we test with a specific dolphinrc configuration? Or should we delete that file for testing?

Suggestions:

Can you add an "ignore" feature (not simply "hide" the display of the entry, but more like "do not access") that would avoid placing unwanted system mount points in user-places.xbel?

1. I did further testing on two desktop computers. I used the same user-places.xbel file on both. (Copying the file from one computer to the other seems to work fine.) The large version of that file increases Dolphin startup time by at least 400% on both computers. On the faster computer, Dolphin startup time goes from 0.49 seconds to 2.045 seconds. (The effect is greater on the other computer.)

Deleting the user-places.xbel file results in dramatic speed up. 

Using a file with more entries (including entries on NFS mounts and with custom icons) results in dramatic slow down. This is confirmation of what I reported earlier after more testing on the second computer. 

On a computer where Dolphin performs very snappy I was able to make it become very sluggish simply by copying the larger user-places.xbel to it (without making any other changes).

2. The slow startup is not just the first time. With Dolphin open, opening a new window is just as slow as the first startup. File dialogs become consistently slow, so it seems whatever is slowing Dolphin down is not being cached.

3. Next I looked at the effect of NFS mounts separate from my Places bookmark entries. I started by deleting user-places.xbel, and let Dolphin create the minimal version. As mentioned, I have 10 NFS mounts defined in /etc/fstab. I timed Dolphin startup time. Then I removed all NFS mounts from /etc/fstab on one computer and umounted all those mounts, and again let Dolphin create a minimal user-places.xbel (which is now very small).

Removing all NFS mounts from the computer makes a further improvement in Dolphin start up time. This reinforces the value of an option in Dolphin to ignore (do not read, access) certain entries in user-places.xbel. Many of mine are never opened in Dolphin, but I have to pay a cost for them every time I open Dolphin or any KDE file dialog.

4. Next I deleted Dolphin settings (~/.config/dolphinrc) and tested that way. Then I manually recreated all my original Dolphin settings (split pane view, etc.). I did not detect any effect on Dolphin startup time. I believe I can rule out dolphinrc as being responsible for a significant startup delay.

Bottom line: it's user-places.xbel, NFS mounts and maybe folder icons. And the effect of these things on Dolphin startup time KDE file dialogs is huge.

> Bottom line: it's user-places.xbel, NFS mounts and maybe folder icons. And the effect of these things on Dolphin startup time KDE file dialogs is huge.

NFS mounts are like very slow Hard drives, so it implies slow IO, and folder icons adds IO since dolphin has to scan for those settings that are currently spread out (bug https://bugs.kde.org/show_bug.cgi?id=322922) which means dolphin is slowed down even more when the two are combined.
But this should not cause this much delay.

But mostly what you are describing about the user-places.xbel make me thing it is a duplicate of https://bugs.kde.org/show_bug.cgi?id=393977

Could you confirm once you get KDE Frameworks 5.71 whether this is fixed.

Hi. This issue is not resolved.
I have:
KDE Frameworks 5.72.0
Qt 5.15.0 (built against 5.15.0)
Dolphin Version 20.04.3
plasmashell 5.19.4
OS: Arch Linux [linux version 5.7.11-arch1-1]

BTW, https://bugs.kde.org/show_bug.cgi?id=393977 is not resolved for me either.

The original problem I reported in 2018 still exists:

bugreporter11 2018-05-07 23:07:01 UTC

Dolphin has become slow recently. In particular, adding or moving a bookmark in the Places panel has a delay of several seconds.

To reproduce, create a new bookmark in Places or move an existing bookmark up or down in the Places panel. There is a delay of a few seconds. Previously, there was no noticeable delay. I now experience these delays 100% of the time.

No such slowness with dialogues on FreeBSD 14.0-CURRENT. 

Please: with the most recent software, on other platforms, is this still an issue?

(In reply to bugreporter11 from comment #0)
> SUMMARY
> 
> Dolphin, as well as KDE file dialogs in all KDE applications, open very
> slowly. It takes several seconds for the file-open dialog to display in Kate
> or any other application. Also, it takes several seconds for Dolphin to
> display any window content on first opening. 
> 
> After it is open, Dolphin does not have slow responsiveness (except as
> related to Bug 393977). 
> 
> STEPS TO REPRODUCE
> On my system, the steps are this simple:
> A. open Dolphin
> B. or bring up the File Open dialog in Kate or any other KDE application
> that uses KDE's file dialogs
> 
> OBSERVED RESULT
> 
> I have to wait several seconds before I see a file dialog appear, or before
> Dophin shows any content in its window.
> 
> Even on a fast desktop system (such as a modern Intel i7 with NVMe disk and
> plenty of RAM), there is a delay of several seconds before Dolphin will
> populate the windows contents or before a KDE file dialog will open/display. 
> 
> EXPECTED RESULT
> 
> No delay. 
> 
> GTK file dialogs (on the same system running Plasma 5) open instantly.
> Dolphin and KDE file dialogs should open almost as quickly. Other software
> on this system is not slow.
> 
> 
> SOFTWARE/OS VERSIONS
> Arch Linux
> KDE Plasma Version: 5.18.5 (from About System Settings)
> KDE Frameworks Version: 5.70.0
> Qt Version: Qt 5.14.2 (built against 5.14.2)
> proprietary nVidia driver
> 
> HARDWARE
> 
> This is a modern desktop computer with Intel i7 CPU, fast NVMe disk, 32GB
> RAM, fast nVidia GPU.
> The hardware is not slow.
> 
> OTHER BUGS
> 
> I do not believe this is related to bug 169929 because once Dolphin in open,
> it responds normally (except as related to Bug 393977). 
> 
> It is also not related to bug 179955 because print dialogs open quickly. I
> only see file dialogs and Dolphin having slowness.

Hi!

System: 

Operating System: Debian GNU/Linux 11
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-16-amd64
OS Type: 64-bit
Processors: 2 × Intel® Pentium® D CPU 3.00GHz
Memory: 5.8 ГиБ of RAM
Graphics Processor: GeForce GTS 450/PCIe/SSE2

Exactly same problem. But, here is solution:

https://bbs.archlinux.org/viewtopic.php?pid=2055908#p2055908

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!    In short: rename, move or delete files ~/.config/QtProject.conf  !!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

In my case, problem was solved. Try it.

I have the same issue (file open dialog took 9-10 seconds to show up). After reading this bug report and the comments I finally tried deleting ` ~/.local/share/user-places.xbel` and that resolved the problem for me.

The original file had over 21,000 lines, the newly generated has only 198 lines.
The original file was over and over full with entries from kdeconnect (i have only one paired device but there were hundreds of entries) and hundreds entries about docker layers.

I guess this bug is related to 
* #466416 KDE Connect keeps adding devices to Dolphin over and over and over and over and over
* #451876 Dolphin slow start takes almost 5-6 seconds
* #398908 Dolphin uses up huge amounts of memory over time

(In reply to Henrik Gebauer from comment #16)
> I have the same issue (file open dialog took 9-10 seconds to show up). After
> reading this bug report and the comments I finally tried deleting `
> ~/.local/share/user-places.xbel` and that resolved the problem for me.
> 
> The original file had over 21,000 lines, the newly generated has only 198
> lines.
> The original file was over and over full with entries from kdeconnect (i
> have only one paired device but there were hundreds of entries) and hundreds
> entries about docker layers.
> 
> I guess this bug is related to 
> * #466416 KDE Connect keeps adding devices to Dolphin over and over and over
> and over and over
> * #451876 Dolphin slow start takes almost 5-6 seconds
> * #398908 Dolphin uses up huge amounts of memory over time

I'm the OP. Thanks for your comment. That helps. I have had this issue for years and it is not resolved. Maybe those other bug reports will help. I also think you are right about a large ~/.local/share/user-places.xbel being part of the problem.  Mine is currently 14617 lines. It has thousands of kdeconnect entries in it.

I do not want to delete the entire file because I have well organized Dolphin bookmarks that I invested a lot of time in creating.

(In reply to bugreporter11 from comment #17)
> (In reply to Henrik Gebauer from comment #16)
> > I have the same issue (file open dialog took 9-10 seconds to show up). After
> > reading this bug report and the comments I finally tried deleting `
> > ~/.local/share/user-places.xbel` and that resolved the problem for me.
> > 
> > The original file had over 21,000 lines, the newly generated has only 198
> > lines.
> > The original file was over and over full with entries from kdeconnect (i
> > have only one paired device but there were hundreds of entries) and hundreds
> > entries about docker layers.
> > 
> > I guess this bug is related to 
> > * #466416 KDE Connect keeps adding devices to Dolphin over and over and over
> > and over and over
> > * #451876 Dolphin slow start takes almost 5-6 seconds
> > * #398908 Dolphin uses up huge amounts of memory over time
> 
> I'm the OP. Thanks for your comment. That helps. I have had this issue for
> years and it is not resolved. Maybe those other bug reports will help. I
> also think you are right about a large ~/.local/share/user-places.xbel being
> part of the problem.  Mine is currently 14617 lines. It has thousands of
> kdeconnect entries in it.
> 
> I do not want to delete the entire file because I have well organized
> Dolphin bookmarks that I invested a lot of time in creating.

You should be able to remove the unnecessary kdeconnect entries.

Could anyone share their lenghthy ~/.local/share/user-places.xbel ?
Only the kdeconnect entries part would be sufficient.
That would help diagnose what goes wrong with kdeconnect adding all those entries.
I don't reproduce it myself.k

> Could anyone share their lenghthy ~/.local/share/user-places.xbel ?
> Only the kdeconnect entries part would be sufficient.

This is the entry. (I replaced some content by "xxxxx" because I'm not sure if it should be considered sensitive information)

There are 1449 copies of the following entry in my file. They are all identical except for the <ID> part. The <ID> is often repeating only with a different number after the /.

<bookmark href="kdeconnect://cb14c18fd15xxxxx/">
  <title>SM-G525F</title>
  <info>
   <metadata owner="http://freedesktop.org">
    <bookmark:icon name="kdeconnect"/>
   </metadata>
   <metadata owner="http://www.kde.org">
    <ID>16402xxxxx/2</ID>
   </metadata>
  </info>
 </bookmark>

(In reply to Henrik Gebauer from comment #19)
> > Could anyone share their lenghthy ~/.local/share/user-places.xbel ?
> > Only the kdeconnect entries part would be sufficient.
> 
> This is the entry. (I replaced some content by "xxxxx" because I'm not sure
> if it should be considered sensitive information)
> 
> There are 1449 copies of the following entry in my file. They are all
> identical except for the <ID> part. The <ID> is often repeating only with a
> different number after the /.
> 
> <bookmark href="kdeconnect://cb14c18fd15xxxxx/">
>   <title>SM-G525F</title>
>   <info>
>    <metadata owner="http://freedesktop.org">
>     <bookmark:icon name="kdeconnect"/>
>    </metadata>
>    <metadata owner="http://www.kde.org">
>     <ID>16402xxxxx/2</ID>
>    </metadata>
>   </info>
>  </bookmark>

I don't know how somehow so many kdeconnect bookmarks were created.
I don't have such issue with on my systems while using kdeconnect.
This seem to point to a bug in kdeconnect.

(In reply to Méven Car from comment #20)
> I don't know how somehow so many kdeconnect bookmarks were created.
> I don't have such issue with on my systems while using kdeconnect.
> This seem to point to a bug in kdeconnect.

I think so. Maybe the "Product" entry in this bug report should be changed to kdeconnect so people from there will have a look at it.

(In reply to Méven Car from comment #20)
> 
> I don't know how somehow so many kdeconnect bookmarks were created.
> I don't have such issue with on my systems while using kdeconnect.
> This seem to point to a bug in kdeconnect.

I had the same problem.

I think the root cause is that the device uses MAC randomization, so every time it connects with a different MAC address, a new entry will be created.

Thanks for your help!

I have some additional information. 

After few months after deleting file ~/.config/QtProject.conf it grew up at 180MB and opening file dialogs begun to freeze again.

Here is simple solution - delete file, wait while it will be created, and disable writing rights. As i can see, file don't grow anymore and all work fine.

I think this bug is not specific enough and might mix up several issues. I mark this bug as a duplicate of Bug 451876, which addresses most significant portion of this bug about user-places.xbel.

*** This bug has been marked as a duplicate of bug 451876 ***

( if there is another cause for the slow responsiveness in your case, please open another specific bug report about that cause)

This is not a duplicate of Bug 451876. 

My ~/.local/share/user-places.xbel was originally only 389 lines. After I deleted it, the new file is only 269 lines. But I still experience the bug as explained by the bug reporter. 

I use autofs to mount my SAMBA shares, no NFS shares, but even after I disable the autofs service, I still experience the dolphin startup delay and file dialog delay. 


Operating System: Arch Linux 
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.9-zen2-1-zen (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i7-1180G7 @ 1.30GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: LENOVO
Product Name: 20UQS12G00
System Version: ThinkPad X1 Nano Gen 1

(In reply to Fredric from comment #26)
> This is not a duplicate of Bug 451876. 
> 
> My ~/.local/share/user-places.xbel was originally only 389 lines. After I
> deleted it, the new file is only 269 lines. But I still experience the bug
> as explained by the bug reporter. 

please see the comments I gave directly above (comment #24, comment #25)
> I think this bug is not specific enough and might mix up several issues. 

> (if there is another cause for the slow responsiveness in your case, please
> open another specific bug report about that cause)

*** This bug has been marked as a duplicate of bug 451876 ***

(In reply to Fredric from comment #26)
> This is not a duplicate of Bug 451876. 
> 
> My ~/.local/share/user-places.xbel was originally only 389 lines. After I
> deleted it, the new file is only 269 lines. But I still experience the bug
> as explained by the bug reporter. 
> 
> I use autofs to mount my SAMBA shares, no NFS shares, but even after I
> disable the autofs service, I still experience the dolphin startup delay and
> file dialog delay. 
> 
> 
> Operating System: Arch Linux 
> KDE Plasma Version: 5.27.9
> KDE Frameworks Version: 5.111.0
> Qt Version: 5.15.11
> Kernel Version: 6.5.9-zen2-1-zen (64-bit)
> Graphics Platform: X11
> Processors: 8 × 11th Gen Intel® Core™ i7-1180G7 @ 1.30GHz
> Memory: 15.3 GiB of RAM
> Graphics Processor: Mesa Intel® Xe Graphics
> Manufacturer: LENOVO
> Product Name: 20UQS12G00
> System Version: ThinkPad X1 Nano Gen 1

Since I can't reproduce your issue and no one else it seems, you are the one in the best position to investigate.

If you have some technical skills, you could record use hotspot (https://github.com/KDAB/hotspot, it is in AUR in version 1.4.1) to determine what is taking dolphin so long.
You first need to get debug symbols, you should have debuginfod on your system. Running `gdb dolphin` then type r in the console, the debug symbols should be downloaded, once the dolphin window shows up, you can close it and use hotspot.
Running hotspot will require to run `echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid` to allow it to observe files.

Then you can screenshot the flamegraph, or try to identify which functions and taking too long to finish.

Created attachment 163029 [details]
Hotspot Top Down

Created attachment 163030 [details]
Hotspot Bottom Up

Created attachment 163031 [details]
Hotspot Flame Graph

(In reply to Méven Car from comment #28)
> Then you can screenshot the flamegraph, or try to identify which functions
> and taking too long to finish.

Thanks for the instructions. 
I have attached the screenshots of the hotspot. 

Please let me know if there's any other way I can investigate or solve this bug.

(In reply to Fredric from comment #32)
> (In reply to Méven Car from comment #28)
> > Then you can screenshot the flamegraph, or try to identify which functions
> > and taking too long to finish.
> 
> Thanks for the instructions. 
> I have attached the screenshots of the hotspot. 
> 

Awesome work, thank you for the effort !
That the best kind of feedback we can hope for to solve performance issues.
Unfortunately it is not simple to share result as they are versions specific.

> Please let me know if there's any other way I can investigate or solve this
> bug.

Hard to spot anything very fishy on the screenshots.

A long time is spent fetching thumbnails.
Do you have the same issue if you disable the thumbnail in the dialog (shortcut F12) ?

How many files are are in the folder ? What file types are the files in the folder ?

If this is not it, since the issue is the startup delay, in the flamegraph could you filter & zoom on the startup of the dialog if you can spot it.

Keep in mind that if most of the time is spent waiting (for I/O, network, mutex....) then using hotspot to look at CPU cycles will tell you nothing. You want to check the "off-CPU profiling" checkbox in hotspot, and look at wait times (in the flamegraph, look at the combobox which says "cycles", change it to "off-CPU Time").
If you get errors about sched_wait or something, run this script: http://www.davidfaure.fr/kde/perf-init

(In reply to Méven Car from comment #33)

> A long time is spent fetching thumbnails.
> Do you have the same issue if you disable the thumbnail in the dialog
> (shortcut F12) ?

Yes.


> How many files are are in the folder ? What file types are the files in the
> folder ?

71 folders, 15 other items in home folder (startup folder).
Just some text, images, PDFs, just normal files. 

> If this is not it, since the issue is the startup delay, in the flamegraph
> could you filter & zoom on the startup of the dialog if you can spot it.

I can't spot it. 


I tried creating a new empty folder in root: /abc/
If I set it as startup folder, there's no delay in new dolphin window, but if I navigate from /abc/ to Home folder, or other folders, the folder opens right away but as soon as the folder content shows up, Dolphin will hang for about 5-15 seconds. 

If I add only 1 folder in /abc/, when I open a new Dolphin window, it will hang for about 5-15 seconds as well before responding to my input.

(In reply to David Faure from comment #34)
> Keep in mind that if most of the time is spent waiting (for I/O, network,
> mutex....) then using hotspot to look at CPU cycles will tell you nothing.

Yes. KSysGuard doesn't show any CPU spike during Dolphin startup and delays.

> You want to check the "off-CPU profiling" checkbox in hotspot, and look at
> wait times (in the flamegraph, look at the combobox which says "cycles",
> change it to "off-CPU Time").
> If you get errors about sched_wait or something, run this script:
> http://www.davidfaure.fr/kde/perf-init

I have run the script. 
If I check the "off-CPU profiling" checkbox, 

> privileges elevated!
> $ perf record -o /home/fr/perf.data --call-graph dwarf,8192 --event cycles --switch-events --event sched:sched_switch --aio -z --sample-cpu /usr/bin/dolphin
> restoring privileges...

Dolphin window doesn't show up, and I can't stop recording. When I click the "Stop Recording (...min ...s)" it changes to "Stop Recording" but the Hotspot app becomes unresponsive and I can't shutdown normally due to the perf process.