Re: [Telepathy] Folks status, the addressbook problem

On Tue, 2012-10-30 at 15:40 +0100, Xavier Claessens wrote:
I've recently looked again at Folks performance and it's not good. I've
been working on N900 and N9 addressbooks and they are not really good
neither, even if we achieved in both cases good enough performance for
real commercial product. But can we make Folks the perfect solution if
we take the time to do it properly?


A couple of other things which I just thought of. There are three main
problems with folks at the moment (listed roughly in descending order of
importance, as I see it):

 1. Speed. Aggregation is unacceptably slow. Most other things are fine,
from the profiling I did a few months ago.

 2. Testing. Folks doesn’t have enough unit tests or the testing
infrastructure to support them. It doesn’t have enough profiling
infrastructure, so we don’t even know how bad (or good) points (1) and
(3) are.

 3. Memory consumption. Folks consumes far too much memory, due to
having to duplicate data from its backends, and due to clients generally
duplicating data from folks. Memory allocations are duplicated between
clients, and common data isn’t shared. A move towards sharing pages
between folks clients would be good (either by making folks a daemon, or
by careful use of memory mapping).

But it has some major good points:

 A. It’s used widely, and is largely stable.

 B. Aggregation works.

 C. It’s network transparent. Any changes I make to folks on my laptop
will also appear on my desktop.

Any changes to folks should address points (1), (2) and (3), but should
definitely not break (A) or (B). This suggests to me that a major
redesign of folks probably isn’t a good idea. I may be being too
conservative. I may also be out of touch with folks development, since I
haven’t done any proper work on it for several months. Take everything I
say with a pinch of salt.

Daemonising folks would reduce memory consumption (although perhaps not
dramatically, unless clients stopped duplicating all of the data they
got out of folks) and would amortise startup/aggregation time across
clients. However, I suspect it would suffer from having to transmit a
lot of data across D-Bus. From the profiling I did, it seems that a
significant proportion of the startup time for the EDS backend in folks
is spent transmitting EDS contacts across D-Bus. If folks was
daemonised, folks clients would suffer from this as well.

Finally, this discussion should be happening on the folks mailing list,
not the Telepathy one. I’ve CCed it in.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]