Summary: | Gwenview is slow on huge dirs | ||
---|---|---|---|
Product: | [Applications] gwenview | Reporter: | rnet723 |
Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | avatar, bugseforuns, jtamate, myriam, nate, postix, strong.drum0546, tom.mbrt |
Priority: | NOR | Keywords: | efficiency-and-performance |
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=402802 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | remove all references to KFileItem::mimetype in order to demonstrate the probelm |
Description
rnet723
2016-09-23 18:09:38 UTC
*** This bug has been marked as a duplicate of bug 341594 *** Actually, probably not a dupe. 150k files is a lot. Trying to see one directory containing ~82k images (12,6 Gb) from: http://msvocds.blob.core.windows.net/coco2014/train2014.zip Gwenview takes more than 5 minutes to start showing thumbnails, while dolphin 18.04.1 (with https://phabricator.kde.org/D10742 applied) starts creating thumbnails in less than 5 seconds. bug 404542 seems related I had a quick look at this and I understand it as follows: After a call to ContextManager::setCurrentDirUrl() (i.e. opening a directory in the thumbnail view), KDirLister::openUrl() is called. This one will add all files in that directory one-by-one to the Gwenview::SortedDirModel. One-by-one a row is inserted into this model. Every insert emits the rowsInserted signal. Every such signal will call ThumbnailView::rowsInserted(). In there, another rowsInsertedSignal will be emitted which goes to PreviewItemDelegate::slotRowsChanged() to update some hover selection or so. And we do that as many times as there are files in the directory - 82783 times - in the UI thread... and once we are done with that, the thumbnail generation can finally start. Created attachment 173427 [details]
remove all references to KFileItem::mimetype in order to demonstrate the probelm
I had the same problem. Only 600 files but over sshfs, took about 20 seconds before it showed the first thumbnail. Looking at gstack, it seems that it spends all of the time in KFileItem::mimetype, so it looks like gwenview wants to know the mime type of every single file before it does anything else. I confirmed this by ripping out every call to KFileItem::mimetype and now it starts showing thumbnails and becomes responsive immediately upon startup. Attaching the diff against 25719c42e64210608488f17641c2308f2fe12f9d, will let someone closer to gwenview think of a proper solution. Hi, I'm a bit late to the party, nevertheless... Tested two different versions 25.04.2 (Plasma 6.3.5) and latest development version 25.07.70. Samba mounted in Dolphin opening dir with hundreds of screenshots. On the old version I can confirm, you wait about a minute or so until screenshot generation starts, on the new version it starts almost immediately. Seems they have optimized this already, however I don't know if 6.4 will contain this. I'll change this to needsinfo so it reminds us in 14 d, by then 6.4 will be out I believe and at the latest I will then re-check. (In reply to Lenzoid from comment #8) > Hi, I'm a bit late to the party, nevertheless... Tested two different > versions 25.04.2 (Plasma 6.3.5) and latest development version 25.07.70. > Samba mounted in Dolphin opening dir with hundreds of screenshots. On the > old version I can confirm, you wait about a minute or so until screenshot > generation starts, on the new version it starts almost immediately. > > Seems they have optimized this already, however I don't know if 6.4 will > contain this. I'll change this to needsinfo so it reminds us in 14 d, by > then 6.4 will be out I believe and at the latest I will then re-check. I have a directory with over 150,000 images, and even sorting the list of files takes minutes, BEFORE preview generation starts. Gewnview 25.04.1, Plasma 6.3.5, KF 6.14. Cannot test on newer versions. ๐๐งน โ ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! ๐๐งน This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |