Re: [Evolution-hackers] Getting rid of shipped libdb

[Rob Bradford <rob robster org uk>]

On Tue, 2008-10-07 at 18:14 +0100, Michael Meeks wrote:
> Hi Rob,
> 
> On Tue, 2008-10-07 at 16:49 +0100, Rob Bradford wrote:
> > Hhh. But. The use case you outlined directly above about where this goes
> > wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> > that migrates it to Some Other Format (tm). You then add some contacts
> > which go into the new format. Then you go back to your old machine.
> > *Boing*. Same problem, your new contacts are missing :-(" 
> 
> 	Yes true - but at least, this is a once-and-for-all fix ;-) and of
> course there is no reason to say that we can't sync them to the old db
> format too for a while.

Ack.

> > I would expect migrating from one version of GNOME and then back again
> > is probably pretty problematic anyway...ultimately I think you need to
> > draw the line at some point.
> 
> 	True - but having a problem at -every- version point, and across ~every
> distribution such that "I used SUSE and now I can't switch back to
> FooBaked Linux !" is not good ;-)

Ack. Although i'd have thought we'd have seen more bugs relating to
people upgrading...through several generations e.g. Ubuntu.

> > Somewhat orthogonally: Also, I wonder on the performance impact of the
> > flat-file approach wrt, modification / deletion when dealing with ~1k
> > contacts.
> 
> 	Fast enough I guess; I have ~3k real-life contacts, and that is ~1.5Mb
> of addressbook.db [ which seems pretty much a flat vcard file when you
> read it ;-].

Okay.

> 
> 	It seems my pmap is struggling to work ATM, but it'd be interesting to
> know how much of addressbook.db is 'hot' in e-d-s anyway.

For queries that Evolution does the summary is used quite extensively. 
The summary is an in-memory cache which is then serialised out to disk.
Searching is therefore an O(n) strcmp exercise. For just the reading
case i'd expect to find that the database is not very hot since the
summary should help with a lot of the searching. From the summary you'd
get the UID you were lookibg for and then can do an efficient (hashed)
UID based lookup to find the VCARD.

I did some work to replace this with a bdb index:

http://bit.ly/1GrCPL

This had the benefit of being more flexible about the fields you could
index and  you get some better performance for queries since you can
exploit the hash to help you find what you're looking for. (As an aside
there is also the memory impact of not having to have the summary in
memory perpetually.)

Cheerio,

Rob