I have 3000ish contacts and when I do a search in the Filter box, each keystroke triggers the filtering algorithm. Reproducible: Always Steps to Reproduce: 1. Enable several accounts to get 1000 of contacts. 2. Open the contactlist; start a search/filter with Ctrl+F 3. Write a name at normal typing speed. Actual Results: You notice that a search is performed on each keystroke. Expected Results: The Filter algorithm should be delayed for half a second or so, to allow the user to type his search terms keeping the UI responsive. Then some UI feedback code should show the window as busy while searching. Workaround: I write my search terms in kwrite and then copy them to the filter box; this is much faster and more responsive. This is just a minor annoyance. KDE Telepathy has become my IM platform of choice. Keep up the good work.
Thanks for the report. I can confirm this happening. I guess we could add a simple if (contacts.size() > 500) { delaySearching(); } Btw. in the meantime you can also use KRunner to search for your contacts, that should be way more responsive ;)
We've made some parts of the model faster. Please retest to see if this is actually needed.
Thanks for your work. Tested your git commit 593a1a48 and there's no change in search responsiveness.
Thanks. Can you check you have 1417fd90f1b07de2badf3cf4ff208c8da1702c60 in libkpeople too? This is the one that makes data() faster, the commit you linked was purely for grouping. I'd like to try and optimise before we add in a workaround; it'll make all the things faster. There was some work to do in the KTpTranslationProxyModel.
Sorry; I was using the downstream libraries. I compiled the libkpeople master and the situation improved considerably; search took ~3 seconds before, now it takes ~1 sec on the first letter.
I've got a callgrind output from just the filtering. We are spending a /lot/ of time in QImage::load() (30% of my time filtering) we call it more often that we call paintRow. Which means something is wrong. QPixmap has an implicit cache when given a path, QImage does not; we are probably loading a whole image every time we repaint. We spend 9% of the time in QPixmap::scaled() so maybe we should keep a QPixmapCache of the scaled avatars. That really means changing the API from libkpeople, as we would need some sort of string identifier for the image. Lets fix that, it'll probably give us a boost, and then we can look and see if we need to optimise anything else.
Created attachment 86320 [details] Callgrind logs for filtering
We spend another 9% of the time in KTp::dataForKtpContact. This code is relatively slow; which is fine as it's only meant to be used when we are invoking an action. The sorting function includes ContactClientTypesRole, which goes via this function, it ends up getting called > 9000 times whilst I was searching. If we proxy the clientTypes as a custom field in libkpeople we will save a lot.
Sorry for the noise: >That really means changing the API from libkpeople, as we would need some sort of string identifier for the image. Edit: QPixmap::cacheKey solves that.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.