[Kde-pim] Excessive amount of queries

Daniel Vrátil dvratil at redhat.com
Thu Dec 4 15:55:58 GMT 2014


On Monday 01 of December 2014 14:40:58 Christian Mollekopf wrote:
> On Monday 01 December 2014 13.39:50 Milian Wolff wrote:
> > On Monday 01 December 2014 12:50:36 Christian Mollekopf wrote:
> > > On Monday 01 December 2014 12.29:39 Milian Wolff wrote:
> > > > Hello all,
> > > > 
> > > > I know you are all thinking about Akonadi Next, but I'd love to see
> > > > some
> > > > work on improving the Akonadi we have now, and will have for quite
> > > > some
> > > > time.
> > > > 
> > > > When you enable the query debugger in akonadiconsole, you'll see that
> > > > just
> > > > switching to a different email in KMail, will easily end up triggering
> > > > ~200
> > > > queries. Can someone with more knowledge tell me if really all of that
> > > > is
> > > > required?
> > > 
> > > I doubt it but would have to look at the actual queries.
> > 
> > with this patch, it's trivial for you to check it: There is also a
> > screenshot attached of some results for me.
> > 
> > https://git.reviewboard.kde.org/r/121307/
> 
> Jup, that could very well be LIST with statistics and attributes.

Stats are very expensive. I want to try to cache the statistics internally, 
and flush the cache when collection changes. I believe that could be some 
performance improvement and query reduction.

> 
> > > > I'm in the process of improving the query debugger interface, to
> > > > aggregate information on queries. That should show us better which
> > > > queries
> > > > are triggered repeatedly and take a long time.
> > > 
> > > One part that I improved in the kolab branches that did not yet make it
> > > upstream is refactoring LIST so it doesn't do recursive queries. This is
> > > where a single CollectionFetchJob can easily trigger N queries where N
> > > is
> > > the number of folders you have. So in case you stumble over that, be
> > > aware
> > > that this should be already solved somewhere (and that I will merge that
> > > upstream as well).
> > 
> > Yes, I think that is the main culprit. Can you please backport that to
> > 1.13?
> I'll have to discuss with Daniel how we go about that.

I can manually cherry-pick stuff from your branches into upstream, which means 
I will also review them. Unfortunately we can't get all the changes in, 
because some of them require changes in kdepimlibs too.

Dan

> 
> Cheers,
> Christian
> 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141204/3aca18da/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list