General Performance Issues Viewing Large Pictures

[Maik Qualmann]

Setting the cache manually doesn't make sense. It's not that a lot helps a 
lot. Of course I've experimented with larger caches, if it made sense we would 
of course do it. A cache must be managed, if changes are made to the image, 
the cache data is discarded. There may be changes affecting the image such as 
color profile, rotation, size and more.

Maik

Am Montag, 26. Juni 2023, 23:00:56 CEST schrieb Thomas D:
> With raw photos and panoramic photos it is not unusual with each photo
> being between 20-50MB each.
> 1GB is only 20 photos of 50 MB.
> 
> I would really like at least an option to specify cache size manually to
> either a specific size or as a percentage of physical ram.
> 
> Would it be problematic to add such option?
> 
> I have a 16GB MacBook also in which I would very much like more than 1GB on
> as well. Because when I do serious photo stuff I don’t do much else. So I
> would like to utilize my resources.
> 
> The penalty of not having an image in cache often involves fetching it over
> the network on a SAN.
> 
> man. 26. jun. 2023 kl. 22.18 skrev Maik Qualmann <metzpinguin at gmail.com>:
> > I adjusted it again, from about 16GB main memory it will be about 1 GB
> > cache.
> > Much more doesn't make sense since we always preload two images into the
> > cache
> > (before and after the current position). Depending on the size of the
> > images,
> > more will be retained when scrolling back and forth.
> > 
> > Maik
> > 
> > Am Montag, 26. Juni 2023, 22:07:06 CEST schrieb Tonio Kroeger:
> > > WAAAAAHHHHHHHH! :-) Yes 64GB. And now everything makes sense. Moreover I
> > > had a try with: digiKam-8.1.0-20230617T074456-x86-64.appimage
> > > The difference is tremendous. Thanks a lot!
> > > 
> > > Tonio
> > > 
> > > On Mon, Jun 26, 2023 at 6:42 PM Maik Qualmann <metzpinguin at gmail.com>
> > 
> > wrote:
> > > > Is the specification of 64GB for the memory correct?
> > > > With this size, we calculate the image cache incorrectly, only a very
> > > > small
> > > > cache is created, so no larger images are preloaded in the preview.
> > > > The
> > > > problem will be fixed in digiKam-8.1.0.
> > > > 
> > > > Maik
> > > > 
> > > > Am Montag, 26. Juni 2023, 18:12:19 CEST schrieb Tonio Kroeger:
> > > > > Hi all,
> > > > > 
> > > > > I am an enthusiastic digikam user for nearly 20 years now!
> > > > > 
> > > > > I am running 8.0.0. on an I7 under Linux with plenty of RAM (
> > 
> > https://www.intel.com/content/www/us/en/products/sku/205608/intel-nuc-11-p
> > 
> > > > ro>
> > > > 
> > > > > -mini-pc-nuc11tnkv7/specifications.html). My picture collection
> > 
> > became
> > 
> > > > huge,
> > > > 
> > > > > about 8TB (also many RAW files, roughly 300.000 Jpegs), and I still
> > 
> > use
> > 
> > > > > SQLLite for the database.
> > > > > 
> > > > > In general everything works fine but when I switch to another
> > > > > picture
> > > > 
> > > > this
> > > > 
> > > > > takes up to 3 seconds. This is very anyoing especially when sorting
> > 
> > out
> > 
> > > > > pictures. For the latter purpose I store incoming pictues on the
> > > > > internal
> > > > > SSD but this leads exactly to the 3 seconds from above, external
> > > > 
> > > > USB-drive
> > > > 
> > > > > is worse but not as worse as I would expect. I tried to precache all
> > > > > pictures into RAM, that did not significantly help. When I lower the
> > > > > maximal CPU frequency this seems to scale linearly with the time to
> > 
> > show
> > 
> > > > a
> > > > 
> > > > > new picture.
> > > > > 
> > > > > Over the years my pictures became larger and larger. Today I have
> > 
> > Jpegs
> > 
> > > > > around 20MB. (5MB Pics from my IPhone show up very fast.)
> > > > > 
> > > > > I wonder whether someone can give a hint where I might have an issue
> > > > > with
> > > > > my system. Is SQLLite a problem in my setting? Or are the 3 seconds
> > 
> > just
> > 
> > > > my
> > > > 
> > > > > fate because of the many megapixel...
> > > > > 
> > > > > Best wishes & tnx
> > > > > 
> > > > > Tonio