Bug 303994 - Many face tag comboboxes and may tags, will have an impact on performance [patch]
Summary: Many face tag comboboxes and may tags, will have an impact on performance [pa...
Status: CLOSED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 2.7.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-24 09:07 UTC by Kristian Karl
Modified: 2017-08-15 18:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 2.8.0


Attachments
Sceenshot of an image with a lot of face tag combo boxes. (806.79 KB, image/png)
2012-07-24 09:17 UTC, Kristian Karl
Details
Don't sync if it's already performed (1.40 KB, patch)
2012-07-28 15:20 UTC, Kristian Karl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Karl 2012-07-24 09:07:50 UTC
Adding a lot of face tags on an image, and having a lot of tags in 'My tags', will hurt the performance of digikam.

How to reproduce:
==============
1) Start digikam, make sure you have +100 tags in 'My tags'
2) Add 2 images to a album
3) View image 1 by clicking on it (preview)
4) Enable 'Show Face Tags'
5) Manually add a 50 face tags to image 1. (Do not assign any tags, only add the face tag with the combo boxes)
6) Switch to preview image 2
7) Switch back to preview image 1
8) Repeat steps 6) and 7), and notice how the loading of image 1 gets slower and slower

I tried to troubleshoot this behavior, but did not manage to solve it. I noticed though, that digikam spent a lot of time in ModelCompletion::sync [core/libs/widgets/common/modelcompletion.cpp]
I enabled (un-commenting) the 2 kDebug() @ lines 244-245 and 260, saw what to me appeared a growth of calls to ModelCompletion::sync for each added [d->addItem(face); ==> core/utilities/facedetection/facegroup.cpp @ line 617] AssignNameWidgets. But I failed to understand why so many calls where made to ModelCompletion::sync, and from where they originated.

This never stopped growing, so that explained why digikam ran slower and slower when opening an image with a lot of AssignNameWidgets in it.

Reproducible: Always
Comment 1 Kristian Karl 2012-07-24 09:17:31 UTC
Created attachment 72721 [details]
Sceenshot of an image with a lot of face tag combo boxes.

I used this image to reproduce the problem.
The problem also occurs with images with only a few face tag combo boxes on it, it only takes longer for the problem to occur.
Comment 2 Marcel Wiesweg 2012-07-25 18:10:22 UTC
CPU or memory usage?
Comment 3 Kristian Karl 2012-07-26 09:33:32 UTC
CPU usage.
When I enabled the logging I mentioned above, I easily came to millions of calls to   ModelCompletion::sync(QAbstractItemModel* model, const QModelIndex& index) [core/libs/widgets/common/modelcompletion.cpp @ line number257]
Comment 4 Kristian Karl 2012-07-28 15:20:33 UTC
Created attachment 72805 [details]
Don't sync if it's already performed

This patch fixes the performance problem. But I'm not claiming it to be a final solution, because I do not fully understand the implications or any side effects of this patch.
Comment 5 Marcel Wiesweg 2012-07-29 12:58:28 UTC
Git commit a9aaa60c26b03e5f0b445aa78bea97fb165ebc36 by Marcel Wiesweg.
Committed on 29/07/2012 at 14:57.
Pushed by mwiesweg into branch 'master'.

Check that the new source model is not actually already the source model. Qt does not seem to make this test.

M  +9    -3    libs/models/albumfiltermodel.cpp

http://commits.kde.org/digikam/a9aaa60c26b03e5f0b445aa78bea97fb165ebc36
Comment 6 Marcel Wiesweg 2012-07-29 13:01:48 UTC
I believe this is the problem: We have 1 set of models and n completion objects. When creating each new widget, the two filter models change their source model, which resets the model, even if there is no actual change and the source model is already set. As we share the model, adding widget x will resync all 1..x completion objects, which means we will resync n + (n-1) + (n-2) + ... times.
Please check if my fix solves the problem.
Comment 7 Kristian Karl 2012-07-29 13:29:34 UTC
Yes, this solves the problem.

(In reply to comment #6)
> I believe this is the problem: We have 1 set of models and n completion
> objects. When creating each new widget, the two filter models change their
> source model, which resets the model, even if there is no actual change and
> the source model is already set. As we share the model, adding widget x will
> resync all 1..x completion objects, which means we will resync n + (n-1) +
> (n-2) + ... times.
> Please check if my fix solves the problem.