IRC on-join sluggishness, profiled

[Paul Aurich]

I spent a little time this afternoon playing with callgrind and profiling
the new IRC prpl behavior, in 2.8.0.  (As a side note, anyone know of a
good replacement for kcachegrind that doesn't require I install a crapton
of KDE libs?).  This was done profiling joins to #pidgin and #freenode (I
tried #ubuntu, but gave up after it was still running once I'd finished a
full episode of The Simpsons)

I've attached one patch which greatly improves purple_conv_chat_cb_find's
behavior (it's a significant pig), though we'd need to bump up to 2.9.0
with this.

The remaining big chunk of time is spent in this call chain:
	irc_msg_who
		purple_conv_chat_user_set_flags
			pidgin_conv_chat_update_user
		purple_conv_chat_cb_set_attributes
			pidgin_conv_chat_update_user

This is naturally called once for each user in the WHO, and there are a few
issues with pidgin_conv_chat_update_user:

1) It has an O(n) (n = size of list) search for the current row for the
chat entry

2) The search calls purple_utf8_strcasecmp, which, if I'm reading this
kcachegrind output right (no guarantee of that), is over half of the cycles
spent in pidgin_conv_chat_update_user.

3) removes and re-adds the row to the list store (this is 11% of the cycles
for pidgin_conv_chat_update_user)

4) Reinserting the row is totally useless for this specific update type.

I'm not sufficiently familiar with the GTK conversation code and gtk list
store/tree view code to know if there's a more efficient way to handle #1
and #3.

#2 could be addressed by forklifting into gtkconv.c a search function which
uses g_utf8_collate_key

#4 is problematic; ideally we could just add a new signal for updating the
attributes and use that instead of the context-less UI op it currently uses
(this could be construed as a backward-incompatible change, although the
only user of this code at the moment is Adium, and as they bundle a binary
libpurple in, it wouldn't be an issue for them to update to match new
semantics).

~Paul
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://pidgin.im/pipermail/devel/attachments/20110618/22191ec1/attachment-0002.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110618/22191ec1/attachment.sig>