Data Structures

[Ankit Vani]

One data structure I can think of other than what Richard mentioned is
circular buffers (libpurple/circbuffer.[ch]).

As for optimizing, search for things in the code marked 'TODO', maybe
something will pop up for you.

For example, see this in libpurple/account.h:

/*
 * TODO: Supplementing the next two linked lists with hash tables
 * should help performance a lot when these lists are long.  This
 * matters quite a bit for protocols like MSN, where all your
 * buddies are added to your permit list.  Currently we have to
 * iterate through the entire list if we want to check if someone
 * is permitted or denied.  We should do this for 3.0.0.
 * Or maybe use a GTree.
 */
GSList *permit;             /**< Permit list.                           */
GSList *deny;               /**< Deny list.                             */


On Tue, Nov 19, 2013 at 10:54 AM, Richard Laager <rlaager at wiktel.com> wrote:
> I don't know that I can speak to things that need optimizing, but you'll
> find a variety of data structures in Pidgin. Of course, this is all
> about the *use* of them, as the actual implementations are provided by
> glib.
>
> A few things that jump to my mind:
>
> - Check out libpurple/stringref.[ch] for an interesting data structure
> not provided by glib.
>
> - We use lots of linked lists, both single- and double-linked.
>
> - The buddy list (libpurple/blist.[ch]) is a tree.
>
> - The logging code also has some hash table stuff going on with "log
> sets", which are used to populate autocomplete lists. There are other
> areas that use hash tables; this is just one I'm familiar with.
>
> - This may not be as relevant any more, but at the time this change was
> implemented, the logging code benefited a lot from switching to glib's
> slice allocator. (Though that's maybe not directly a "data structures"
> thing.) It also benefited slightly from avoiding zero'ing the allocated
> structs; that's probably not even noticable these days.
>
> --
> Richard