Valgrind-massif shows the following usage of the heap in gabble: ->10.27% (643,386B) 0x47C0209: standard_malloc (gmem.c:88) | ->10.26% (642,747B) 0x47C0750: g_malloc (gmem.c:164) | | ->05.11% (320,171B) 0x47D88C9: g_strdup (gstrfuncs.c:102) | | | ->01.74% (108,836B) 0x44660C2: tp_contacts_mixin_set_contact_attribute (in /usr/lib/libtelepathy-glib.so.0.61.0) | | | | ->00.38% (23,760B) 0x8135A65: conn_client_types_fill_contact_attributes (conn-client-types.c:165) | | | | | ->00.38% (23,760B) 0x4465D32: tp_contacts_mixin_get_contact_attributes (in /usr/lib/libtelepathy-glib.so.0.61.0) In my tests, I have 330 contacts. It means the string "org.freedesktop.Telepathy.Connection.Interface.ClientTypes/client-types" uses 23kbytes of memory. The string "org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities/capabilities" also uses 23kbytes of memory. In total, tp_contacts_mixin_set_contact_attribute() is responsible for 108kbytes of memory, most of it is just a few strings strdup'ed for each contact. Could GQuarks be used instead of duplicating strings?
I thought that all these duplicate strings were allocated and kept in memory permanently but it is only transient allocations for the need of replying to: - Connection.Interface.Contacts.GetContactAttributes() - Connection.Interface.ContactList.GetContactListAttributes() And the strings are freed after the D-Bus message is sent.
(In reply to comment #0) > Could GQuarks be used instead of duplicating strings? That would be nice; in the meantime, tp_contacts_mixin_set_contact_attribute() could be changed to use g_intern_string() or similar without breaking its API, I guess?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/72.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.