Hello digiKam Users,
digiKam Version: 5.4.0 (via Homebrew) OS: macOS OS Version: 10.12.3 (Sierra) PC Specs: Intel core i5, 4GB RAM I'm currently working on a project that requires I use a VERY LARGE number of tags. And by "VERY LARGE", I mean on the order of 220,000. After reading the digiKam database spec, I wrote a quick Python script to read my tag set in from a source JSON document and add it to the digiKam database using the sqlite3 library. This did not make digiKam happy. When I attempted to launch it after adding the tags, it hung indefinitely at the loading screen step labeled "Reading the Database..." I verified that I hadn't mangled the database format, then tried again, only to be met with the same hang. By reducing the number of tags 85% (33,000), I was able to convince digiKam to start again, but it took 10 minutes for it to open... Is this a supported use case? Is there a box I can check somewhere to tweak digiKam's database loading system to handle absurd numbers of tags? If not, would a code contribution to try to speed up tag loading be welcome? - Alex |
The problem is not the tags amount in fact, and not the database. The problem is located in search text widget used to filter tree-view. When you start digiKam the widget is populated with tags a album name to provide auto completion. The loop inside the Qt widget model is like O(n^2) and hang-up. The possible solution is to disable autocompletion in this areas for the moment. The problem is reported in this file : .. and also already reported in this room... The problem is identified at least. We need a strategy to prevent this dysfunction. Gilles Caulier 2017-02-19 16:30 GMT+01:00 Alexander Langley <[hidden email]>: Hello digiKam Users, |
In reply to this post by Alexander Langley
Ah, I see. I apologize for not doing sufficient research before sending mail to the list. Is it possible to disable autocompletion without recompiling from source?
- Alex On Feb 19, 2017, 11:51 -0500, Gilles Caulier <[hidden email]>, wrote:
|
Well, I know that Maik, have performed some investigations and apply some patches. Just report and comment on bugzilla, he is in CC. We will see... Gilles Caulier 2017-02-19 17:59 GMT+01:00 Alexander Langley <[hidden email]>:
|
I am not sure if this will help, but for QCompleter implementation,
allows to specify if the model is sorted or not. If the elements are sorted, and we specify this with http://doc.qt.io/qt-4.8/qcompleter.html#modelSorting-prop, we can get a huge improvement, because of binary search vs normal search. On Sun, Feb 19, 2017 at 6:03 PM, Gilles Caulier <[hidden email]> wrote: > Well, I know that Maik, have performed some investigations and apply some > patches. Just report and comment on bugzilla, he is in CC. We will see... > > Gilles Caulier > > 2017-02-19 17:59 GMT+01:00 Alexander Langley > <[hidden email]>: >> >> Ah, I see. I apologize for not doing sufficient research before sending >> mail to the list. Is it possible to disable autocompletion without >> recompiling from source? >> >> - Alex >> >> On Feb 19, 2017, 11:51 -0500, Gilles Caulier <[hidden email]>, >> wrote: >> >> >> The problem is not the tags amount in fact, and not the database. >> >> The problem is located in search text widget used to filter tree-view. >> When >> you start digiKam the widget is populated with tags a album name to >> provide >> auto completion. The loop inside the Qt widget model is like O(n^2) and >> hang-up. >> >> The possible solution is to disable autocompletion in this areas for the >> moment. >> >> The problem is reported in this file : >> >> https://bugs.kde.org/show_bug.cgi?id=367853 >> >> .. and also already reported in this room... >> >> The problem is identified at least. We need a strategy to prevent this >> dysfunction. >> >> Gilles Caulier >> >> >> >> 2017-02-19 16:30 GMT+01:00 Alexander Langley >> <[hidden email] >> : >> >> Hello digiKam Users, >> >> digiKam Version: 5.4.0 (via Homebrew) >> OS: macOS >> OS Version: 10.12.3 (Sierra) >> PC Specs: Intel core i5, 4GB RAM >> >> I'm currently working on a project that requires I use a VERY LARGE number >> of >> tags. And by "VERY LARGE", I mean on the order of 220,000. After reading >> the >> digiKam database spec, I wrote a quick Python script to read my tag set in >> from >> a source JSON document and add it to the digiKam database using the >> sqlite3 >> library. >> >> This did not make digiKam happy. When I attempted to launch it after >> adding the >> tags, it hung indefinitely at the loading screen step labeled "Reading the >> Database..." I verified that I hadn't mangled the database format, then >> tried >> again, only to be met with the same hang. By reducing the number of tags >> 85% >> (33,000), I was able to convince digiKam to start again, but it took 10 >> minutes >> for it to open... >> >> Is this a supported use case? Is there a box I can check somewhere to >> tweak >> digiKam's database loading system to handle absurd numbers of tags? If >> not, >> would a code contribution to try to speed up tag loading be welcome? >> >> - Alex > > |
I assume the binary search in QCompleter is only usable when filterMode() == Qt::MatchStartsWith. However, especially for tags the filterMode should be Qt::MatchContains. When I tag a person with "John Smith", I want the tag to show up when I enter "Smith". Furthermore, as described in https://bugs.kde.org/show_bug.cgi?id=373247, sorted order is not always wanted. So if you decide to enable the binary search, please make it configurable On 22 February 2017 at 15:45, Veaceslav Munteanu <[hidden email]> wrote: I am not sure if this will help, but for QCompleter implementation, |
In reply to this post by Veaceslav Munteanu-2
I assume the binary search in QCompleter is only usable when filterMode() == Qt::MatchStartsWith. However, especially for tags the filterMode should be Qt::MatchContains. When I tag a person with "John Smith", I want the tag to show up when I enter "Smith". Furthermore, as described in https://bugs.kde.org/show_ On 22 February 2017 at 15:45, Veaceslav Munteanu <[hidden email]> wrote: I am not sure if this will help, but for QCompleter implementation, |
In reply to this post by Veaceslav Munteanu-2
Hi Veaceslav, Look like the Qcompleter is not really the problem. Maik has fixed the problem already. It's to populate the tree-view with items. It take a while. Giles 2017-02-22 15:45 GMT+01:00 Veaceslav Munteanu <[hidden email]>: I am not sure if this will help, but for QCompleter implementation, |
Free forum by Nabble | Edit this page |