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. Ross -- Ross Burton mail: ross burtonini com jabber: ross burtonini com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part