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?
*snip* 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. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part