Re: [Evolution-hackers] libebook scalability

["Øystein Gisnås" <oystein gisnas net>]

2007/4/2, Ross Burton <ross burtonini com>:
> On Mon, 2007-04-02 at 09:03 +0200, Øystein Gisnås wrote:
> > I'd also love to create scripts, code and test data to test
> > performance of some of the most important functions. Then we would be
> > able to track performance over time in a more scientific way.
>
> http://burtonini.com/bzr/eds-tests/
>
> Check that out with bzr and you get a few tools:
>
> 1) a dummy backend for libedata-book.  Ask for a contact and you get the
> same one back.  As for a contact list and you'll always get the same 10.
> Ask for a book view and (mwhaha) you'll get 100000 contacts.  This makes
> profiling the EDS infrastructure easier as the backend has almost zero
> overhead.  I should probably reduce the number of contacts returned in a
> book view as malloc tends to swamp the profiles now.
>
> 2) eds-bookview.  A test application that will open and repeatedly
> request book views for a given number of times and URL.  For example:
>
> $ eds-bookview --uri dummy:/// --repetition 10 --silent
>
> Will visibly do nothing for a few minutes but EDS will be very busy.
> Attach a profiler and come back 10 minutes later to discover that EVCard
> parsing is still primary bottle neck in eds-dbus.

Very useful.. And a first hands-on bzr for me..

It indeed seems like the vCard is a bottleneck here. One thing is the
CPU cycles for parsing that add up a bit on small datasets. For larger
datasets, the size of the vCard itself adds up a lot. My test with
1*10^6 contacts made a 350MB on the disk, plus a 100MB summary. The
same data in MySQL resulted in a 10MB database.

Øystein