PurpleStatus objects: (numStatusesForAccount) * (numBuddiesForAccount)

[Evan Schoenberg]

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?

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080718/a2c80c2d/attachment.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://pidgin.im/pipermail/devel/attachments/20080718/a2c80c2d/attachment.sig>