[Kde-pim] mailcomposer still hangs (Re: KMail completion spams nepomuk, which isn't parallelized)

[Volker Krause]

On Friday 10 August 2012 22:09:41 Martin Koller wrote:
> On Thursday, 9. August 2012 20:56:07 David Faure wrote:
> > On Thursday 09 August 2012 15:23:05 Shaheed Haque wrote:
> > > Oh, it is "Akonadi::ContactSearchJob" initially that remains in the
> > > "Running" state, hanging the composer window. And I have just noticed,
> > > it *only* gets stuck if I have used address autocompletion.
> > 
> > Indeed, it turns out that I only disabled the "harvest all emails from
> > nepomuk" code (AddresseeLineEdit::Private::startNepomukSearch) but not the
> > "akonadi contact search job", which itself uses nepomuk (!)
> > 
> > We discussed it further in #kontact today, and apart from nepomuk being
> > able to run queries in parallel, we also need akonadi to not wait for
> > that ContactSearchJob anymore. Which seems to require:
> > 1) running these jobs in a different akonadi session, and
> > 2) making it possible to actually kill these jobs, when typing something
> > different and especially when sending the mail (no completion needed
> > anymore).
> A general question about this:
> 
> wouldn't it be much better (performance and complexity wise) that kmail
> would request _all_ known mail addresses when it starts and keep those
> cached internally (and probably registers itself for additional new
> addresses, if that is possible with akonadi/nepomuk) and use ONLY the local
> held internal cache for address completion, which would avoid that (it
> looks for me as) massive overhead to start a new query for every new letter
> the user types just to stop the query again when the next letter is entered
> ?

That's what we did previously, a Kontact with KMail 1 had your address book 
loaded 6-7 times in memory. Didn't scale very well, let alone once "address 
book" is expanded to "everyone you ever interacted with". I'm not saying the 
current situation is optimal, but there are good reasons for using a central 
database-like backend :)

> I assume the list of email addresses a user deals with is rather limited
> (I'd say a few hundred for a business user, and probably a few tens for a
> normal user), so this shouldn't be any problem memory wise.

I think you are massively underestimating these numbers. On my personal 
machine Nepomuk finds about 5.000 distinct contacts/email addresses. On my 
work machine it's about 25.000 (and I'm working for a rather small company). 
Both only index real content, no spam/trash folders etc. of course. I 
basically don't have a manually maintained address book anymore, these are all 
contacts I (or rather Nepomuk) know about from all kinds of sources. 

While it might still fit into memory, it's too large to do simple linear 
search, so you end up managing some kind of index structures, a typical 
database task. And then we are still not looking at grouping, meta-contacts, 
contact avatar images, completion preferences based on usage statistics, or 
any other fancy idea for future improvements.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120813/30fc2950/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/