General Performance Issues Viewing Large Pictures

[Tonio Kroeger]

With digiKam-8.1.0-20230628T051819-x86-64.appimage I get Memory available
62.4 GiB and Image cache size 1.0 GiB.

Behavior is now exactly how you describe. Next image is shown very fast,
immediately clicking next again results in longer delay.

For sorting my "family photos" I am absolutely happy with that behavior.
And actually this is my main task :-)

When I curate my birding pictures more caching maybe would make sense.
Birding in my case means I have bursts of photos, often several hundret
very similar pictures. Typically I delete all but 1%. I do this by skipping
through the pictures in 100%-view.

Best wishes and thanks for this great software!

Tonio



On Tue, Jun 27, 2023 at 12:41 PM Maik Qualmann <metzpinguin at gmail.com>
wrote:

> Again to make sure our DMemoryInfo class is working correctly. Please see
> the
> digiKam component info dialog. How much memory is shown as available on
> your
> system?
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20230630/7763984e/attachment.htm>