Bug 293888 - Poor performance with mounted network locations
Summary: Poor performance with mounted network locations
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Open/save dialogs (show other bugs)
Version: git master
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: triaged
: 309682 318477 323368 342266 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-12 11:50 UTC by Alex
Modified: 2024-02-04 15:43 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2012-02-12 11:50:02 UTC
Version:           1.0 (using KDE 4.8.0) 
OS:                Linux

When saving an image in google chrome, kdialog in special, but the KDE filechooser in general is used. 

When saving the image to a folder with many images, the filechooser behaves slowly. Even in folders with not so many files, the general snapiness is much slower than the gtk-filechooser firefox uses.

There should be some effords to improve the filechoose, so it acts as instantaneous as possible. clicking on a folder should open it and its filelist instantly. Things like thumbnails for images can be loaded lazyly afterwards, but the dialog should react promptly and should be usable within a milliseconds  not seconds, because this really slows down the workflow.

Reproducible: Didn't try

Steps to Reproduce:
use kdialog or another kde program which uses a filechooser to save some file. try to navigage through folders and save the file with some customized filename.

Actual Results:  
the filechooser reacts rather slow, in the range of seconds to a reaction

Expected Results:  
the filechooser should feel "snappy" and react in a time range like 100ms or even faster.

i do not think its specific for kdialog, but a general problem of the kde4 filechooser.

I'm working with the kde desktop, a fast processor and enough ram, so its not a problem like "kde programs are slow when used under gnome" or something like this.
Comment 1 Alex 2012-02-12 17:50:17 UTC
another usability issue:

In the gtk-filechooser, the filename in the input box is selected (without
extension) and the textbox has the focus. so i can either hit enter to save it
with this filename, or just start typing to replace the filename with a better
one.


still trying to collect, which are the things, which make the other filechooser
better. Its more like "okay, this one works quite nice, and this one seems more
complicated" and then you try to figure out what the real differences are.
Comment 2 Alex 2012-04-05 09:23:22 UTC
okay, further ideas what the problems are:

- maybe disable icon-thumbnails by default and provide a preview-image on the right for image-save dialogs. then even in large folders only the preview of the image to be overwritten needs to be loaded.

- it seems generation of the filelist and maybe even starting of the thumbnailer are in the same thread as the Chooser-UI. At least the UI is blocked for serveral seconds depending on the number of files in the folder. It would be better to have this in a background thread, so a user which only wants to save some image just can type the filename in the dialog and click "save" without waiting for the list to be loaded.
Comment 3 kenorb 2012-09-14 11:37:21 UTC
I've the same problem.
When using Chrome 18.0.1025.168 (Developer Build 134367 Linux) on Ubuntu 12.04, the KDialog takes more than 1 minute to show up!

Qt: 4.8.1
KDE Development Platform: 4.8.4 (4.8.4)
KDialog: 1.0

When executed manually the following command:
strace kdialog --attach=71303405 --title=Open File --getopenfilename /home/kenorb/Sites/x/sites/all/modules/contrib/simpletest_clone

It seems to stop on poll for exactly 25 seconds!

write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\225\24\31\0\32\0\300\5\1\0\0\0+\0\0\0\7\0\t\0\377\377\t\0\t\0\0\0\3648\0\0"..., 400}, {NULL, 0}, {"", 0}], 3) = 400
recvfrom(6, 0x7aef44, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.162\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89
recvmsg(7, 0x7fff4ef79770, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
poll([{fd=7, events=POLLIN}], 1, 25000

Are you doing sleep(25) or something? Why?
It happens every time to me when I'm trying to upload anything on any site in Chrome browser.
Comment 4 Christoph Feck 2012-09-14 16:56:56 UTC
Do you have remote folders in Places Panel?
Comment 5 Alex 2012-09-14 17:49:36 UTC
no remote folders. The problem seems to be just a large list of images in the opened folder, which slow the filechooser down.
Comment 6 kenorb 2012-09-17 12:51:20 UTC
Just to confirm, by Filechooser you mean still KDialog? Because I'm confused if we're talking about the same thing. And if our problems is similar, or I should report separate bug?
I don't have any remote folders either.
Comment 7 Alex 2012-09-17 17:52:31 UTC
Isn't the kdialog --getopenfilename Filechoser (as used by Google Chrome) the same as the default filechoser other KDE programs use as well?

I have the problem with chrome, as thats my usecase where i save images from chrome in my Photos folder, but i think the problem may exist for other programs with the filechooser as well.

the problem does not seem to be with remote lookups, but with displaying large file icon lists.
Comment 8 kenorb 2012-09-19 14:43:43 UTC
Thanks, I've created separate Bug 307049
Comment 9 Alex 2012-09-19 19:57:00 UTC
good thing, because my problem IS NOT that the dialog itself does not open, but that the filelist needs long to be filled with icons and be responsive,
Comment 10 gedgon 2012-09-19 21:49:37 UTC
(In reply to comment #9)
[...] but that the filelist needs long to be filled with icons and be responsive,
Not only with lots of files, but like you said before "Even in folders with not so many files, the general snapiness is much slower than the gtk-filechooser firefox uses."

It's very annoying, when simple file chooser needs about 1 sec to pop up, even on fairly modern hardware, like 4 core SB @ 3.3.GHz
Comment 11 Christoph Feck 2013-04-20 09:38:36 UTC
*** Bug 318477 has been marked as a duplicate of this bug. ***
Comment 12 Brallan Aguilar 2013-04-20 20:07:16 UTC
I have the same problem when adjunt files with Kmail. It's annoying...
Comment 13 Brallan Aguilar 2013-05-31 07:23:12 UTC
*** This bug has been confirmed by popular vote. ***
Comment 14 kenorb 2013-05-31 08:27:16 UTC
In my case Filechooser was slow (over 1 minute), because UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with it. In other words, one of the KDE module is blocking the D-Bus system (all d-bus sockets are taken by some other buggy process which was using buggy library (UpdateManager)), especially when using network with proxy. Workaround was to kill the faulty process, in my case it was releasechecker (Python app).
Now releasechecker should be fixed, but the bugs can be everywhere else, as the whole D-Bus implementation and debugging features of it leaves much to be desired.
The easiest way to check what's faulty, is to kill/unload KDE modules one by one and check when it'll actually work.
See more details at:
https://bugs.kde.org/show_bug.cgi?id=307049
Comment 15 Christoph Feck 2013-07-21 13:56:45 UTC
The problem here is that the file dialog is called via the kdialog command, instead of directly from the application, e.g. Chrome.

Even if it looks like a shell program only, kdialog is a "full" KDE application like all other KDE applications. It has to load kconfig, sycoca, mime, icon databases, initialize locale/translation/styling stuff, lauch KIO daemons, etc. Starting it will be slow.
Comment 16 Christoph Feck 2013-07-21 14:40:48 UTC
*** Bug 309682 has been marked as a duplicate of this bug. ***
Comment 17 Alex 2013-07-21 14:52:44 UTC
(In reply to comment #15)
> The problem here is that the file dialog is called via the kdialog command,
> instead of directly from the application, e.g. Chrome.
Nope.
1) I am using KDE, so all the daemons are already running
2) Filechooser-Components in KDE-Programs are slow, too. The problem are the many files in a folder, i guess suppose because of some thumbnailing/metadata reading process.
Comment 18 Niels 2013-08-08 11:39:49 UTC
When I run

kdialog --getsavefilename /folder/with/4000/jpgs/

it takes several minutes for the dialog to become repsonsive. This is also what happens in Chromium and other programs. In practical terms, it's unusable.

However, putting an strace on makes it much faster:

strace kdialog --getsavefilename /folder/with/4000/jpgs/
Comment 19 kenorb 2013-08-08 12:06:03 UTC
@Niels
It's rather not possible that it will run faster when followed by strace. Only if you run it as a different user.
Could you check on which syscall it's freezing and paste it?
Comment 20 Niels 2013-08-09 12:36:31 UTC
I've been working on this for some time now, it's quite hard to nail down. Sometimes the strace / no strace effect is clearly repeatable for an hour, then suddenly it's not. This is through reboots and with no major changes to the system. Sometimes the dialog is quick, mostly it's not. I've tried many things and read many pages, and while I haven't solved the problem, I think it has "mostly gone away".

I've been testing with kdialog from console, save image in Chromium, move image in Gwenview and more. These all appear to work or not work the same. I've never seen Dolphin block like this on any large folder.

Getting rid of gamin made no difference. Removing folders mounted with sshfs in fstab made no difference. Removing some KDE services in System Setting probably didn't do anything.

I can point to two things that apparently make the dialog work again, but it's much too cargo cult-ish for comfort:

- Removing and / or creating subfolders in the large folder, opening the dialog several times.
- Changing view. Tree view usually blocks the dialog, Short and Detailed don't.

I've now had a working system for several hours over several reboots. I'm sure the problem wil reappear as soon as I press "send"...
Comment 21 Christoph Feck 2013-08-11 22:47:00 UTC
*** Bug 323368 has been marked as a duplicate of this bug. ***
Comment 22 Zane Tu 2013-10-23 22:38:49 UTC
Similar problem on Debian sid with KDE v4.10.5. This issue has been around for almost one year on my laptop with an nvidia graphics card.  It occurs to both command-line kdialog and application file dialog such as those used by Chrome, although it usually does not occur right after login. 

(In reply to comment #20)
> It seems to stop on poll for exactly 25 seconds!
Similar delay here. In my case it is 23 seconds of freeze (along with 100% CPU) after I run the following: 
strace kdialog --getsavefilename /folder/containing/2000/files/and/folders
After I run the command above without "strace", however, the kdialog UI hangs for a much longer period of time. (The UI is still not clickable and consumes 100% CPU. It is not until 190 seconds later that the UI becomes responsive. )

(In reply to comment #20)
> - Changing view. Tree view usually blocks the dialog, Short and Detailed
> don't.

In my case, Short View doesn't block the kdialog UI whereas other modes (Tree View, Detailed View and Detailed Tree View) do.
Comment 23 Zane Tu 2013-10-23 22:46:34 UTC
For those Chrome users who need a temporary workaround, consider adding the following line to you ~/.profile so that Chrome no longer uses kdialog: 
export NO_CHROME_KDE_FILE_DIALOG=1
Comment 24 Claudio Benedetti 2013-11-20 10:16:20 UTC
Same problem here: kdialog and all applications using it hang for about 13 secs before running normally; for example when i run Dolphin (both command line or from start menu) the window appears immediately, but the contents only after 13 secs.
I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
CPU never reached 100%.
Comment 25 Claudio Benedetti 2013-12-06 16:57:46 UTC
(In reply to comment #24)
> Same problem here: kdialog and all applications using it hang for about 13
> secs before running normally; for example when i run Dolphin (both command
> line or from start menu) the window appears immediately, but the contents
> only after 13 secs.
> I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
> CPU never reached 100%.

NOTE: I found that by disconnecting the ethernet plug, the kdialog windows revert working correctly; If the I plug back again, the strange behaviour appears again...
Comment 26 Claudio Benedetti 2014-01-07 08:29:51 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > Same problem here: kdialog and all applications using it hang for about 13
> > secs before running normally; for example when i run Dolphin (both command
> > line or from start menu) the window appears immediately, but the contents
> > only after 13 secs.
> > I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
> > CPU never reached 100%.
> 
> NOTE: I found that by disconnecting the ethernet plug, the kdialog windows
> revert working correctly; If the I plug back again, the strange behaviour
> appears again...

I found what caused KDialog to hang in my case: my PC has 2 nics: eth0 and eth1 but only eth0 is plugged to the internal LAN; my machine have a folder exported to some clients via samba, and on smb.conf i changed the following line:

        interfaces = lo eth0 eth1

to 

        interfaces = lo eth0

and after restarting smb services the problem completely disappeared.
Hope this helps.
Comment 27 Alex 2014-01-07 19:09:23 UTC
My PC has two interfaces (eth0, wlan0) and a vpn interface. vpn and wlan0 are connected, eth0 is not.

But i use neither samba nor NFS.
Comment 28 Alex 2014-06-08 20:28:59 UTC
Its not a general kde problem. dolphin is very fast in the same folder, where the standard filechooser (i.e. from ksnapshot) is very slow.
Comment 29 Christoph Feck 2015-01-15 00:02:25 UTC
*** Bug 342266 has been marked as a duplicate of this bug. ***
Comment 30 Nate Graham 2018-04-10 21:06:12 UTC
Is anyone able to reproduce this with KDE Frameworks 5.45?
Comment 31 Alex 2018-04-10 21:18:59 UTC
With 5.44 it seems better. You can still watch the file list building for about a second and scrolling is a bit sluggish, but it is not hanging and I can select a file with a name I already know fast enough.

Its hard to compare to gtk now, because Gtk3 is much worse than the kde filechooser was when reporting the bug, there probably because of mime-magic on every file (which is a bit off topic, if kde isn't having the same issue here).

I can test 5.45 when debian testing gets it.
Comment 32 Nate Graham 2018-04-10 21:23:11 UTC
Thanks, please do! Even if it's not radically better in 5.45 vs 5.44, maybe we can call this fixed anyway.
Comment 33 Andrew Crouthamel 2018-09-28 03:34:28 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 34 Alex 2018-09-28 06:46:32 UTC
Filechooser in a directory with many images and thumbnails turned off:

- The dialog does not hang anymore
- It causes a short time high cpu on one core
- Scrolling is sluggy for the first 5-10 seconds or so, then it gets better
- The first 5-10 seconds have a waiting pointer, which makes it harder to select a file, even when it is possible

This happens each time, but only the first time you see (noticable) hdd activity. So some stuff seems to be cached, but other things still happen each time you open the dialog.

It's kind of WORKSFORME, but possibly there is room for more improvement.
Comment 35 Alex 2018-09-28 06:48:36 UTC
(changing status)
Comment 36 Aaron Williams 2018-09-28 21:25:12 UTC
This problem usually manifested itself when one or more subdirectories were mounted on network filesystems.
Comment 37 Nate Graham 2018-09-28 21:28:26 UTC
That makes sense. We have a lot of blocking calls that don't handle mounted filesystems that well. Kai has been working on this; CCing him.
Comment 38 grannie 2022-01-28 08:02:24 UTC
I just hit this bug when using VirtualBox (choosing an Iso image for a VM). Are there any updates on this?
Comment 39 flan_suse 2022-05-24 22:57:11 UTC
(In reply to grannie from comment #38)
> I just hit this bug when using VirtualBox (choosing an Iso image for a VM).
> Are there any updates on this?

It's only been 10 years. Quit being so impatient. ;)

KDialog continues to be the slow bottleneck on my otherwise fast system.

GTK file chooser runs laps around it.

Generic Qt file chooser runs laps around it.

KDialog is hilariously slow, even for local filesystems. (Slow for network locations *and* local. It's just more noticeable for network shares.) What is KDialog even doing in the background? Examining every single file inside the current directory or something? Listing the contents of a folder should be a smooth process, just like we experience with GTK file chooser, or heck, using the terminal. I'm not even using thumbnail previews, and it's still crawls with KDialog.

One workaround I found in the meantime is to trick applications into using the GTK file chooser instead, but this doesn't work across the board.
Comment 40 Pedro V 2024-02-02 16:36:47 UTC
Isn't this supposed to be part of the more generic Bug #178678 ?
Although the title makes it seem like it's Dolphin-specific, that's just the worst offender and the bug report was turned into a general KIO issue.

(In reply to flan_suse from comment #39)
> KDialog is hilariously slow, even for local filesystems. (Slow for network
> locations *and* local. It's just more noticeable for network shares.)

The issue is with latency-bound I/O strategies.
It should be really uncommon locally unless you are looking at an HDD which happens to get quite a bit of usage elsewhere too.

The file picker appears to show mounts, so it should be still affected by the problems of mounted network locations.
Not sure how often does that info get refreshed, but just a single mount not responding or being too slow can negatively effect user experience as discussed in Bug #454722 .
Comment 41 Alex 2024-02-04 15:43:50 UTC
I am not sure if it is the same. I wouldn't want this bug to be closed if the other only resolves issues caused by network mounts but problem with local folders may persist.