qView
qView copied to clipboard
jurplel
Slow image loading and switching
- OS: [Windows 10 Build 19044.1415]
- qView version: [5.0 64bit]
Image switching and loading speed heavily correlates with image quantity in the given folder. It gets noticeable above 200 images and slows down to a crawl the higher the number.
Image format, disk speed (HDD, SSD), preloading setting and sorting/position has meagre to no impact.
qView 4.0 already had this problem but not as distinct as 5.0.
Yes, seconded. I've got a 10k+ folder and it's basically impossible to even get a an image to load in qView 😂
Ah, you see I have not been testing with folders with that many images. Do you think the loading time increases linearly or at a higher order of magnitude?
Okay I've got more info. This is weird. It seems that this has more to do with if the files in the folder are "discovered" or not. You know how it takes some time for details like creation date and file type to appear ? Well it seems (still not 100% sure but it seems so) that the time it takes for the folder to be entirely discovered is the time it will take before an image can be opened. EDIT: I take all that back. After some more testing, I'm not sure about anything anymore x)
I'm currently doing some more testing with varying folder size.
I tested it with a 100/200/400/2000/4000/6000/8000 folder mainly filled with 1920x1080 .jpg files, on average250-400 KB in size. The increase is pretty predictable, thus most likely nearly linear.
Ok, so maybe the change to make is if the path is the same as the previous folder, to skip repopulating the list of items in the current folder
Load times seem to increase quite a bit more when getting to 10k+ files.
5k folder: 3,5s to open, 6s to switch to next image 7k folder: 5s to open, 10s to switch to next image 14k folder: 21s to open, 44s to switch to next image
Affirmative.
To make approaches: 02k folder 1,4s to open an image. 04k folder 2,6s to open an image. 08k folder 5,3s to open an image. 16k folder 21,5s to open an image.
Possibly related to #442
@Ichisich @LolicoreExpress Have you tried qView 3.0? I have a few folders with 200-300 images and they all load almost instantly with 3.0. It's about the same with 4.0 but noticeably slower with 5.0.
Ok, so maybe the change to make is if the path is the same as the previous folder, to skip repopulating the list of items in the current folder
Can you load the first image and the folder list in separate threads?
@calico-cat968
Yes, qView 3/4 opens images instantly, regardless of image quantity. Only image switching gets somewhat slower, but even with 16k images, switching keeps below one second.
I am also experiencing performance degrade in the version 5.0, with only some tens of PNGs.
First load is fast, but hitting left / right to move to previous / next image takes more than 2 seconds each time, and it's hard to move several images, because the program is rather unresponsive.
macOS Big Sur 11.6
Ps. Can I download the latest 4.x .dmg somewhere? Thanks.
Yes, you can download previous versions here: https://github.com/jurplel/qView/releases
Sorry about this.
Possibly related to #442
@Ichisich @LolicoreExpress Have you tried qView 3.0? I have a few folders with 200-300 images and they all load almost instantly with 3.0. It's about the same with 4.0 but noticeably slower with 5.0.
Yup, I've reverted back to 4.0 for the time being.
Culprit for the slowdown is:
QFileInfoList QVImageCore::getCompatibleFiles()
{
QFileInfoList fileInfoList = currentFileDetails.fileInfo.dir().entryInfoList(qvApp->getFilterList(), QDir::Files);
QMimeDatabase mimeDb;
QList<QByteArray> supportedMimeTypes = QImageReader::supportedMimeTypes();
// Qt 5.15 seems to have added pdf support for QImageReader but it is super broken in qView at the moment
supportedMimeTypes.removeAll("application/pdf");
const QFileInfoList currentFolder = currentFileDetails.fileInfo.dir().entryInfoList();
for (const QFileInfo &fileInfo : currentFolder)
{
QMimeType mimeType = mimeDb.mimeTypeForFile(fileInfo);
if (supportedMimeTypes.contains(mimeType.name().toUtf8()))
{
if (!fileInfoList.contains(fileInfo)) {
fileInfoList.append(fileInfo);
}
}
}
return fileInfoList;
}
Just wanted to filter by mimetype instead of file extension T_T
Updating open with items with
action->setIcon(openWithItem.icon);
is somehow very slow. It takes 25ms per call, and is called probably around thirty times.
Running populateOpenWithMenu in another thread works, but I get
QObject::startTimer: Timers cannot be started from another thread
in the console, as I am using QWidget in another thread, which isn't allowed/doesn't work properly. Open to suggestions on how to speed up QAction::setIcon.
Well, qView 5.0 is not just slow, it's legendary slow. An image in a directory with 30k of files was not opened even in 4 minutes (then I just killed the process).
What the program does?
Technically there is only one thing that is depended on the count of files in a directory — parsing to create a list with the required meta information of files for sorting and navigation purpose.
qView 4.0 opens it in 3.6 second it. Opening the next image also takes the same time. It looks that qView 4.0 handles the directory each time, while it's required to do only once.
Technically and practically qView can be much faster.
I did the demo program for that issue https://github.com/easymodo/qimgv/issues/290, but I think it would be interested also for you.
Here is it: https://github.com/AlttiRi/demo-image-viewer
It shows the image in 150 ms from the program run (in the same 30k files directory). Opening of an image is not depend of the count of the files in the directory.
Also it parses that 30k directory just in 350 ms in a separate thread.
Take a looks at the readme.
BTW, you use https://github.com/jurplel/qView/blob/eee6b693e3694876950bada0d47756803b2aed14/src/qvimagecore.cpp#L291-L299 for sorting.
Check my comment about it in the readme. It's VERY SLOW thing (3200-3600 ms vs 6 ms). In fact it should work up to 600 times faster, but it looks QT does not cache that values, while it should do.
Yes, certainly there is a big problem. I also found that annoying behavior with the open with menu icon that is slowing things down significantly (recent menu icon probably doesn't help in hindsight either).
I was trying to get the update done before my spring semester started (which I did), but unfortunately I don't have time to give qView the attention it needs at the moment :(
Sidenote: I never tested qView with a folder with over 100 images because i have never had that use case. That is a big design oversight on my part, of course.
You might want to consider pulling the release, or at least putting up a dialog when it starts up, because the bad first impression it's going to give people will undermine its reputation. The nightly-2021.05-19.1 build is much better as a latest release. (i.e. the slow image loading is really bad and I'm on an M1 mac).
You might want to consider pulling the release, or at least putting up a dialog when it starts up, because the bad first impression it's going to give people will undermine its reputation. The nightly-2021.05-19.1 build is much better as a latest release. (i.e. the slow image loading is really bad and I'm on an M1 mac).
I'll do something—I'll try to see if I can mitigate the issue at all first
Would you say the latest build is still worse than 4.0 when in very big folders? I think it should be the same as 4.0 except there is an extra delay when loading an image due to the icon issue.
ok, I did some tests, on folders with about 120 images, 2.5-3.5MB each. I opened the first image and then held down the spacebar to advance through them.
On folders on my local SSD, 5.0 opened the images about twice as fast (my perception, not a precise measurement) as 4.0. This was true for the smaller files as well as the larger. nightly-2021.05-19.1 was the same as 4.0.
But on folders on an SMB network share hosted by an old Mac Mini with a spinning disk running macOS 10.13, it was an entirely different picture. 4.0 opens the images about the same speed as the local SSD, nightly-2021.05-19.1 about half as fast or less, but 5.0 took about 5 seconds (i used a stopwatch) for each (so at least 10 times slower if not much more). If i held down the space bar I'd see the beach ball. Sometimes 5.0 would get unresponsive.
So my gut says the SSD and its locality is hiding the underlying issue... the disk access is so fast you can't perceive whatever 5.0 is doing inefficiently.
I am curious how the changes here affect things: https://dev.azure.com/jurplel/qView/_build/results?buildId=1091&view=artifacts&pathAsName=false&type=publishedArtifacts
they should have made the folder dependence the same as 4.0 except the extra delay when loading an image from the icon issue (I thought you were talking about this build at first above)
I open the first image in the SMB network share and then held down the space bar for 10 seconds to see how many images each version would get through in that time. I ran the test a few times for each version, always skipping the first run so that i was consistently testing against a warm disk/network cache:
| version | number of images in 10 secs |
|---|---|
| 4.0 | 31-36 |
| qView-nightly.2021-05-19.1 | 10-14 |
| 5.0 | 2 images at the 10 sec mark with beach ball spinning, then delayed (long after space bar released) advance to the 3rd and 4th image at 17-25 sec mark. |
| qView-nightly-2022-01-17.2 | 16-23 |
Also, the About qView popup for qView-nightly-2022-01-17.2 shows "qView 5.0" instead of what it is, unlike qView-nightly.2021-05-19.1 which says "qView-nightly.2021-05-19.1".
Also, the
About qViewpopup forqView-nightly-2022-01-17.2shows "qView 5.0" instead of what it is, unlikeqView-nightly.2021-05-19.1which says "qView-nightly.2021-05-19.1".
Thanks, I think I broke the pipeline a while ago.
Performance difference could be because of the aforementioned icon issue. I'll let you know when I address it and we can test again. Thank you for your time, I really appreciate it.
Also, since 5.0 release, I fixed a bug specifically causing holding the arrow to not load images properly, so that might not be a fair comparison for 5.0.
Thanks again!
Also I can say that preloading/caching of the adjacent images is not working, while I see in the repo a code for that and it is enabled by default in the settings. (I tested it with qView 4.0)
I added this thing in my demo program, so I can say if you have a preloaded images (QPixmap) the switching is fast. It takes 25 ms for a 45 MP photo, while the loading of that big image takes 350-450 ms.
How to test it: open one image in a folder with big images, wait 500 ms for the preloading is completed, then go to the next (or previous) image — you will see the delay, it means that caching does not work.
UPD:
It can be easily detected by the memory consuming. It shows that qView does not store the preloaded QPixmap.
Memory consuming of my demo program is almost the same as qimgv's one.
It preloads one image before (if exists) the opened image and one after (if exists).
UPD2: Wait, there is a cache limitation, 50 KB and 200 KB. Caching is only for tiny files? Such files even without caching will be opened fast.
The latest source has this issue addressed for the most part. I made a few additional changes that may or may not be worthy of consideration for addition to the project. YMMW. IWOMM (It Works On My Machine). It's still not as fast as I'd like. There is no reason 36 billion screaming opportunities for computing per second can't load a measly 4MB image file faster than the second or so it seems to take.
