<div dir="ltr"><span style="font-size:12.8px">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 </span><a href="https://bugs.kde.org/show_bug.cgi?id=373247" target="_blank" style="font-size:12.8px">https://bugs.kde.org/show_<wbr>bug.cgi?id=373247</a><span style="font-size:12.8px">, sorted order is not always wanted. So if you decide to enable the binary search, please make it configurable</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2017 at 15:45, Veaceslav Munteanu <span dir="ltr"><<a href="mailto:veaceslav.munteanu90@gmail.com" target="_blank">veaceslav.munteanu90@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am not sure if this will help, but for QCompleter implementation,<br>
allows to specify if the model is sorted or not.<br>
<br>
If the elements are sorted, and we specify this with<br>
<a href="http://doc.qt.io/qt-4.8/qcompleter.html#modelSorting-prop" rel="noreferrer" target="_blank">http://doc.qt.io/qt-4.8/<wbr>qcompleter.html#modelSorting-<wbr>prop</a>, we can get<br>
a huge improvement, because of binary search vs normal search.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Feb 19, 2017 at 6:03 PM, Gilles Caulier<br>
<<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>> wrote:<br>
> Well, I know that Maik, have performed some investigations and apply some<br>
> patches. Just report and comment on bugzilla, he is in CC. We will see...<br>
><br>
> Gilles Caulier<br>
><br>
> 2017-02-19 17:59 GMT+01:00 Alexander Langley<br>
> <<a href="mailto:alexander.g.langley@gmail.com">alexander.g.langley@gmail.com</a><wbr>>:<br>
>><br>
>> Ah, I see. I apologize for not doing sufficient research before sending<br>
>> mail to the list. Is it possible to disable autocompletion without<br>
>> recompiling from source?<br>
>><br>
>> - Alex<br>
>><br>
>> On Feb 19, 2017, 11:51 -0500, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>>,<br>
>> wrote:<br>
>><br>
>><br>
>> The problem is not the tags amount in fact, and not the database.<br>
>><br>
>> The problem is located in search text widget used to filter tree-view.<br>
>> When<br>
>> you start digiKam the widget is populated with tags a album name to<br>
>> provide<br>
>> auto completion. The loop inside the Qt widget model is like O(n^2) and<br>
>> hang-up.<br>
>><br>
>> The possible solution is to disable autocompletion in this areas for the<br>
>> moment.<br>
>><br>
>> The problem is reported in this file :<br>
>><br>
>> <a href="https://bugs.kde.org/show_bug.cgi?id=367853" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.<wbr>cgi?id=367853</a><br>
>><br>
>> .. and also already reported in this room...<br>
>><br>
>> The problem is identified at least. We need a strategy to prevent this<br>
>> dysfunction.<br>
>><br>
>> Gilles Caulier<br>
>><br>
>><br>
>><br>
>> 2017-02-19 16:30 GMT+01:00 Alexander Langley<br>
>> <<a href="mailto:alexander.g.langley@gmail.com">alexander.g.langley@gmail.com</a><br>
>> :<br>
>><br>
>> Hello digiKam Users,<br>
>><br>
>> digiKam Version: 5.4.0 (via Homebrew)<br>
>> OS: macOS<br>
>> OS Version: 10.12.3 (Sierra)<br>
>> PC Specs: Intel core i5, 4GB RAM<br>
>><br>
>> I'm currently working on a project that requires I use a VERY LARGE number<br>
>> of<br>
>> tags. And by "VERY LARGE", I mean on the order of 220,000. After reading<br>
>> the<br>
>> digiKam database spec, I wrote a quick Python script to read my tag set in<br>
>> from<br>
>> a source JSON document and add it to the digiKam database using the<br>
>> sqlite3<br>
>> library.<br>
>><br>
>> This did not make digiKam happy. When I attempted to launch it after<br>
>> adding the<br>
>> tags, it hung indefinitely at the loading screen step labeled "Reading the<br>
>> Database..." I verified that I hadn't mangled the database format, then<br>
>> tried<br>
>> again, only to be met with the same hang. By reducing the number of tags<br>
>> 85%<br>
>> (33,000), I was able to convince digiKam to start again, but it took 10<br>
>> minutes<br>
>> for it to open...<br>
>><br>
>> Is this a supported use case? Is there a box I can check somewhere to<br>
>> tweak<br>
>> digiKam's database loading system to handle absurd numbers of tags? If<br>
>> not,<br>
>> would a code contribution to try to speed up tag loading be welcome?<br>
>><br>
>> - Alex<br>
><br>
><br>
</div></div></blockquote></div><br></div>