Using digiKam with a LOT of tags

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Using digiKam with a LOT of tags

Alexander Langley
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
Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Gilles Caulier-4
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,

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

Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Alexander Langley
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:

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
Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Gilles Caulier-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Veaceslav Munteanu-2
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Kusi
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,
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Markus Leuthold
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_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,
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using digiKam with a LOT of tags

Gilles Caulier-4
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,
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
>
>