| Summary: | digikam 5.9.0 slow to start on Mac but rapid on Ubuntu with same database | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MM <digikam-mm> |
| Component: | ColorManagement-Core | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, chrihuc, KDE, KDEOrgMail, metzpinguin |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | 6.2.0 | |
| Sentry Crash Report: | |||
|
Description
MM
2018-09-21 14:37:54 UTC
Definitively, 6.0.0 willbe better on MAcOS. I fixed i a lots of problem relevant of Mysql support (internal thread crash and mariadb integration in the bundle). In other word, under MacOS, forget Mysql support with 5.9.0. WARNING: using 6.0.0, you must backup you database, as the schema changes. Also, yo cannot mix 5.9.0 under Linux and 6.0.0 under MAcOS. Using 6.0.0 want mean to use the current weekly bundle build, not the 6.0.0-beta1 official. My fixes have be done later this release. To make a try, not in production, i recommend to create a test Mysql database. Init and populate the database under Linux, using 6.0.0 AppImage. n a second time, run the 6.0.0 PKG bundle under MAcOS and branch the settings on the new test database. Compare the start up results and report here... Thanks in advance Gilles Caulier My collection is not reaching the 100.000 but around 60.000, nevertheless I have the same issue, or even worse actually. I tried the current builds on the weekend, unfortunately still the same issues. My native Kubuntu needs 2-3 min for the DB scan (Surface Pro 3, Gigabit Ethernet) My Ubuntu VM, roughly the same (Lenovo P51, AC Wifi) My Wife's Mac needs hours... (MacBook 2015, AC Wifi) Files and DB are on a Dell Poweredge T30. I'd be happy to supply any logs to help. Or try DB tests (empty DB e.g.) Best regards Christoph See also here: https://mail.kde.org/pipermail/digikam-users/2018-August/027105.html Git commit e4f7b919623770586acccf027f88c8f36784eb9e by Maik Qualmann. Committed on 01/10/2018 at 19:14. Pushed by mqualmann into branch 'master'. faster scan for new items with MySQL M +14 -39 core/libs/database/collection/collectionscanner.cpp M +0 -3 core/libs/database/collection/collectionscanner.h https://commits.kde.org/digikam/e4f7b919623770586acccf027f88c8f36784eb9e With this commit, the scan here with a local database is about 12x faster (50 seconds => 4 seconds). Over network, the effect can still be greater. Please report. Maik Git commit 5489bf7016bb7e4d80512a08ebc5c907023b80d8 by Maik Qualmann. Committed on 01/10/2018 at 20:02. Pushed by mqualmann into branch 'master'. Collection scanner 18x faster M +14 -15 core/libs/database/collection/collectionscanner.cpp https://commits.kde.org/digikam/5489bf7016bb7e4d80512a08ebc5c907023b80d8 Unfortunately it seems that this didn't fix my problem. Checked yesterday on my Kubuntu VM. After 30min of "loading the database" I stopped it. Will test on the Mac asap. If the splash screen says "loading the database". is not searching for new items, but all albums are loaded. How many albums (directories) does your collection contain? Maik Git commit f27ab9c1051bd0a0bba6e79bc77899c74a7e6bf8 by Maik Qualmann. Committed on 07/10/2018 at 13:47. Pushed by mqualmann into branch 'master'. add a global cache for grouped images When we load the images into the Icon view, we ask each time, whether there are grouped images, with 30000 images in the view are that also 30000 SQL query. With this patch, the time to load a view with many images is faster with MySQL 3x and with SQLite 2x. Related: bug 391840, bug 396086, bug 397901 M +24 -0 core/libs/database/coredb/coredb.cpp M +5 -0 core/libs/database/coredb/coredb.h M +1 -10 core/libs/database/item/imageinfo.cpp M +19 -2 core/libs/database/item/imageinfocache.cpp M +7 -0 core/libs/database/item/imageinfocache.h M +0 -3 core/libs/database/item/imageinfodata.h https://commits.kde.org/digikam/f27ab9c1051bd0a0bba6e79bc77899c74a7e6bf8 Thanks Maik for the explanation, I have around 2300 folders in the Albums. Why are the loading times so different depending on the OS setup? Regards, Christoph The 2300 albums are no problem for digiKam. Gilles, can you confirm that digiKam is slower under OSX than under Linux? Maik I never test with 2300 album under OSX. I will check this evening. Gilles I realized I might have put you on a wrong path there, as on the VirtualMachine I have, the startup also pauses quite a bit. The VM is running Kubuntu. What else could have an impact? Is something wrong with my DB? Regards, Christoph Any news on this? Did you test on your machine Gilles? Any proposal what I shoudl test? Thanks Christoph Not yet tested. In fact, i'm actually fix a lots of dysfunctions reproducible with unit test around Exiv2, which do not support at all multithreding. This libray used by digiKam must handle all photo metadata, and API is not thread safe and digiKam threads crashes while database is populated or album are scanned. So these dyfunctions will introduce side effect, time latency, and database holes which will slow down digiKam. So, i want to complete this task before to test. Gilles Caulier Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just released ? https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/ What's about he digiKam 6.1.0 pre release package for MacOSX available here : https://files.kde.org/digikam/ This improve time loading at startup ? Thanks in advance Gilles Caulier It got stuck when loading the ICC profiles. Is this something I can fix? Hi, - Disable color management to solve quickly your problem. - Run digiKam from a terminal. You will see a lots of debug traces. Enable color management and look which error is generated on the console and try to identify which color profile is problematic. Executable under MAcoOS is located here : /opt/digikam/Applications/KF5/digikam.app/Contents/MacOS/digikam Gilles Caulier Hi, I disabled the color management in the digikamrc file, didn't help. Starting from the terminal also didn't show me any errors. I'm using digikam for the moment with a local database, this way my wife can at least browse the pictures. Git commit 1f8edbda8bff2a3e201b8870a686f0066e20d590 by Maik Qualmann. Committed on 22/04/2019 at 18:35. Pushed by mqualmann into branch 'master'. use QReadWriteLock for the CollectionManager Loading a large item view is now about 4x faster here with MySQL Related: bug 397901, bug 391115, bug 391840 M +12 -13 core/libs/database/collection/collectionmanager.cpp M +1 -1 core/libs/database/collection/collectionmanager.h M +11 -9 core/libs/database/collection/collectionmanager_album.cpp M +118 -107 core/libs/database/collection/collectionmanager_location.cpp M +1 -1 core/libs/database/collection/collectionmanager_p.cpp M +2 -0 core/libs/database/collection/collectionmanager_p.h M +1 -1 core/libs/database/coredb/coredbaccess.cpp https://invent.kde.org/kde/digikam/commit/1f8edbda8bff2a3e201b8870a686f0066e20d590 Git commit 8a2cbc6917d48bbc5d0b02b78d7bcda4176688cb by Maik Qualmann. Committed on 23/05/2019 at 19:10. Pushed by mqualmann into branch 'master'. QFileSystemWatcher can now be disabled. The setting is on the collection page. The default is off. Related: bug 407691, bug 406224, bug 403073 M +21 -13 core/libs/album/engine/albumwatch.cpp M +2 -0 core/libs/settings/applicationsettings.cpp M +3 -0 core/libs/settings/applicationsettings.h M +10 -0 core/libs/settings/applicationsettings_albums.cpp M +3 -0 core/libs/settings/applicationsettings_p.cpp M +3 -0 core/libs/settings/applicationsettings_p.h M +16 -14 core/utilities/setup/collections/setupcollections.cpp https://invent.kde.org/kde/digikam/commit/8a2cbc6917d48bbc5d0b02b78d7bcda4176688cb Hey Gents, not sure when it was fixed, but with the latest weekly build of 6.2 it's good now. Digikam starts up fairly fast on the Mac with MySQL as Database and wifi as network. Awesome. Thank you! Ok, thanks for the feedback. I close the bug now, if necessary open again. Maik Hello all, I am the original poster for this bug. I would like to confirm that I agree this is now fixed. Digikam 6.3 on MacOS 10.13.6 starts rapidly and runs at what looks like the same speed as Ubuntu. Thanks to all those who contributed to this. It is very useful to me that this is cross platform. Thanks for the feedback Gilles Caulier |