2007/4/2, Ross Burton <[EMAIL PROTECTED]>: > 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 _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
