nedit-ng icon indicating copy to clipboard operation
nedit-ng copied to clipboard

Open File dialog unusably slow on moderate-latency sshfs mount

Open itszor opened this issue 5 years ago • 5 comments

Hi,

First of all, I'd like to say thank you for doing this -- I've been using nedit for a long time, and this port to Qt looks like it'll provide some nice benefits.

One unfortunate problem that prevents me from adopting this version immediately though is that I do a lot of work editing files on remote systems (think transatlantic hops) via sshfs. With nedit-ng, and also other Qt or GTK-based software, the file open dialog is terribly, terribly slow with this setup. Big directories can take minutes to open. With original nedit/Motif, browsing through directory trees (etc.) is perfectly fast (just like doing plain "ls" is).

This seems to be because Qt does a stat() on every file in the directory -- and maybe even probes the first bytes of files? -- which isn't really necessary when the only thing we're interested in is plain text.

Anyway. I guess this is probably impossible to solve within nedit-ng, but I thought I'd throw it out there. (I also tried mounting my remote systems with NFS tunneled over SSH, which is awkward, and worked no better, JFYI.)

itszor avatar Jul 11 '18 15:07 itszor

Yea... I'm not exactly sure how I would go about trying to solve this, but I'll certainly look into it!

This may be better solved upstream in Qt itself though

eteran avatar Jul 11 '18 18:07 eteran

So, the Qt documentation says that QFileDialog::DontUseCustomDirectoryIcons may help:

Always use the default directory icon. Some platforms allow the user to set a different icon. Custom icon lookup cause a big performance impact over network or removable drives. Setting this will enable the QFileIconProvider::DontUseCustomDirectoryIcons option in the icon provider. This enum value was added in Qt 5.2.

The latest in master has this flag being set, please let me know if it makes any difference at all. Though there are a bunch of upstream bug reports involving different circumstances that QFileDialog is slow, so there may be only so much that we can do.

eteran avatar Jul 12 '18 03:07 eteran

I tried the before/after versions with a stopwatch, opening a "gcc" source directory containing 889 files and directories. In both the before/after cases with the Qt5 (5.10.1, Debian) file dialog, opening the directory took about 13 minutes (!). Old nedit linked against Motif 2.3.8 takes ~1 second to open the same directory.

So unfortunately, it doesn't look like that flag helps much, if at all, in this case. Thanks for trying and for the quick response, though!

itszor avatar Jul 16 '18 15:07 itszor

Some more (probably useless) data points: "time ls -l" in that directory (with cold caches) takes 1.2 seconds. "time head *" in the directory takes about 12 mins 45 seconds (about the same as QFileDialog).

itszor avatar Jul 16 '18 15:07 itszor

Yea, so I've been able to replicate this bug by attempting to list files in a large directory of on my NAS. Indeed it takes forever.

Unfortunately, I think that this is a long-standing Qt issue where it does the equivalent of a stat of every file in the directory (even if I tell it not to default to a detailed view!). So I think your original theory is confirmed :-/.

I think that the only real "solution" would be the make an entirely custom dialog which would avoid this behavior... but I imagine that it's non-trivial to get all of the corner cases just right. I'll look into it, but I can't promise that I'll have a solution for this issue quickly.

eteran avatar Jul 16 '18 23:07 eteran