Michael, http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=7798 and http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=7797 were some of the issues I mentioned.
My previous statement was wrong. It wasn't the cache, that is appended, but the summary of the contacts. Just check .evolution/addressbook/<account>/<book_name>.summary -- Summary which is in memory for fast autocompletion and .evolution/cache/addressbook/<account>/<book_name>/cache.db --Acutal cache of contacts If you see these with groupwise, at times the summary will be more than the cache. Which is what the revision fixes. Just check and lemme know. -Srini. On Thu, 2008-01-24 at 17:46 +0000, Michael Meeks wrote: > Hi dudie, > > So - I started to look at the e-d-s memory explosion situation quickly, > took a nice dump from gdb, ran strings on it and the heap has a ton of > strings around the place (as you would expect) - [ currently running at > only ~60Mb > > strings /tmp/eds-heap | sort | uniq -c | sort -n > > gives me: > > 1666 -CONTACT-UID > 1666 -NAME > 1736 ION-DEST-NAME > 1894 OLUTION-BOOK-URI > 2100 -EMAIL > 2184 ION-DEST-EMAIL > 2318 OLUTION-FILE-AS > 2506 OLUTION-LIST > 2992 ION-LIST > 3058 comp > 3321 OLUTION-DEST-EMAIL > 3329 OLUTION-DEST-CONTACT-UID > 3993 OLUTION-DEST-NAME > 4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book > 5343 BEGIN:VCARD > 5372 ION-DEST-EMAIL > 5504 END:VCARD > 5505 VERSION:3.0 > 6786 ION-DEST-NAME > 8606 para > 12739 ION-DEST-CONTACT-UID > 13642 OLUTION-DEST-CONTACT-UID > 18082 OLUTION-DEST-NAME > 19252 OLUTION-DEST-EMAIL > 21991 prop > 32508 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION; > 40253 pA, > > > Where the first column is the count ... 32508 copies of that ATTENDEE > string seems a little excessive, as do the (apparently mangled?) > OLUTION-DEST-... strings. > > Does that provide any insight wrt. code to audit for this huge leak ? > apparently it afflicts everything from SLED10-SP1 onwards. Also - in > general to reduce the (high) e-d-s memory usage, should we be using > GQuarks for some of these field names as we store them ? > > Thanks, > > Michael. > _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers