First loading of heavy folders takes a lot of time on HDD

[tsujan]

Folders like /usr/bin, for example, take ~20 sec to load the first time after a boot.

Since Dolphin shows the contents of such folders almost instantly, there should be a way to load them much faster with pcmanfm-qt too.

[tsujan]

Unfortunately, this isn't fixed after lxqt/libfm-qt#63. pcmanfm-qt is extremely slow in this regard although very fast otherwise.

[tsujan]

Of course, the time depends on the hard drive too: SSD is very fast. However, it's still a mystery to me why Dolphin is so fast in this regard. There may be a problem in libfm-qt or, perhaps, this is what can be expected from GIO. Two timers in the code could reveal the truth.

[tsujan]

Update:

It's GIO: the directory list job takes almost all the time needed for loading the folder but our Qt GUI is extremely fast afterward. Not our fault.

[jonesmz]

I'm a bit confused why this is closed.

The part of the overall program that is slow may be from GVFS, but it's still the lxqt desktop that manifests the problem to the end user.

If this issue was still opened, instead of closed, i would not have opened a new issue.

[tsujan]

The issue is closed because its cause is out of our control. GIO is developed by Gnome devs and they've replied to similar reports by saying that there's no other way; use SSD (not my reply; I don't have the link but really found such an answer).

How do I know that it's all about GIO/GVFS? I did many tests, which I didn't mention here (lack of time). The conclusion was #462 (comment).

[jonesmz]

Ok, I understand that you don't intend to fix this.

However, I really don't find the explanation satisfactory. Somehow other file manager programs are able to provide instant directory listing results even for directories with hundreds of thousands of files, but not lxqt.

The Gnome developers are clearly wrong, and their advice to use an SSD is a non-sequitur.

Additionally, this problem isn't just the first loading of a folder. It's every load of every folder, and it's substantially worse for folders that are mounted over the network, to the point of taking multiple minutes. This makes using pcmanfm-qt with network folders nearly useless.

My advice is that you re-open this bug even if you don't intend to fix it, because it's a bug in the pcmanfm-qt file browser, regardless of whether the problem is caused by an upstream component.

[tsujan]

LONG, CODING COMMENT (not a reply)

Closed issues don't disappear; they're closed for a reason. But I'm reopening this one, for another reason that will be explained at the end of the following, long explanation (written to be a probable start point).

The slowness is only caused by the GIO's G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE and g_file_info_get_content_type. Wherever they are used, there will be a slowdown because the contents of files, that lack extensions, should be read for finding their mimetypes. Almost all the time is taken by that; the other operations are done pretty fast — particularly, the Qt GUI takes no time in comparison.

The Qt GUI needs to wait for all mimetypes to be determined in order to show a folder correctly.

All this can also be easily verified by using Nautilus and without coding: If a huge local folder is first opened by Nautilus (which will take the same time), it'll be opened fast by pcmanfm-qt afterward because the info will be cached. Nautilus and pcmanfm-qt are very different apps but both use GIO and GVFS.

In one experiment, I used Qt's mimetype handling instead of GLib's. It was a little slower. Apparently, GLib does the best possible job.

That being said, I'm still not sure that a workaround isn't impossible because an idea came to my mind while experimenting with Qt's mimetype handling: What if we could use g_file_info_get_content_type only after the files are listed? The current code structure doesn't allow that, of course. But, is it possible to make changes for that purpose?

I think, if the answer to the last question is "yes", the changes should be very fundamental. Sadly, fundamental changes will introduce serious regressions.

Thunar shows that there's hope. Apparently, when it opens a huge folder, Thunar "cheats" by quickly showing items and only then, doing intense file reading for a long time (the same time that Nautilus and pcmanfm-qt take to show the contents), so that, for example, wheel scrolling will be interrupted for a while (an inevitable side effect).

Still having no idea about those "fundamental changes" and really doubting their effectiveness, I accept Gnome's solution ("Use SSD!") for now but reopen this page, without promising anything.

The page will be closed if either a solution is found or it's shown that the above-mentioned plan isn't good.

[es20490446e]

Perhaps determining file mimes, and copying files, could be done in parallel. In a producer-consumer fashion.

[tsujan]

No. There isn't any way out of this situation other than "cheating", which will have its own side effects if possible (read above).

[es20490446e]

I understand. Have a nice day.