[Adium-devl] Top 10 malloc call stacks in Adium

[Evan Schoenberg]

On Jul 18, 2008, at 2:56 PM, David Smith wrote:

> 	Using the wonderful malloc_history -all_by_count tool I have a
> document with a list of every memory allocation call stack in Adium
> (as of when I ran the report), grouped, and sorted by frequency. I've
> put the top 10* here: http://dscoder.com/adiumtop10mallocs.txt
>
> Some things immediately stand out:
>
> 1) 3 functions are responsible for our top 10 malloc callstacks:
> purple_buddy_new
I just sent an email to pidgin-devel regarding this one:

Evan wrote:
> We currently allocate a ton of PurpleStatus objects.  Specifically,  
> whenever a PurpleBuddy is allocated:
>  	purple_buddy_new –> purple_presence_new_for_buddy –>  
> purple_prpl_get_statuses –> purple_status_new
> where purple_prpl_get_statuses() creates a PurpleStatus for each  
> status the buddy's account supports.
>
> However, the only places we use an inactive status are:
>  1. purple_presence_get_status() - which looks up a PurpleStatus by  
> status_id
>  2. tcl_cmd_presence() - which I guess obtains the possible statuses  
> for use by tcl
>
> Otherwise, for every PurpleBuddy on, for example, MSN, we have 10  
> PurpleStatus objects, a maximum of 3 of which are in use at any time  
> (if the buddy has a tune set and is mobile) since 7 of them are  
> exclusive.  For a list with 100 buddies, that means there are 700  
> PurpleStatus objects, each with associated objects, including a  
> PurpleValue per supported attribute, which are only used when  
> looking them up to switch to them (or when TCL does it's thing; I  
> don't claim to know anything about TCL).
>
> Is this a necessary allocation evil? Or could we be lazier about  
> generation of these objects to bring them into being only as needed,  
> destroying them when done?


On Jul 18, 2008, at 2:56 PM, David Smith wrote:
> [AIPreferenceContainer prefs], and
> CFHTTPCookieStorageCopyCookiesForURL

I don't know there's anything we can do about these two.   
AIPreferenceContainer's allocations are from loading the preference  
dictinaries. CFHTTPCookieStorageCopyCookiesForURL() is being called by  
the NSConnection thread as needed.

> 2) (this is more informational, you can't tell it from the document)
> All 18000+ of the #1 call stack happen even with no internet
> connection, and therefore no active connections. In fact, once it's
> done those 18000 all at once on startup, that call stack never appears
> again.

*nod* The libpurple blist.xml is loaded and parsed at startup;  
PurpleBuddy and associated objects are immediately created.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080718/f4823a4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080718/f4823a4a/attachment.sig>