a at nevitus.org
Tue Nov 19 02:56:59 EST 2013
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
> 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.
More information about the Devel