Contact list search slow on older Macs

What kind of computer are you on that it's "abysmally slow"?

The suggestion I got out of this semi-insulting ticket is that perhaps we should allow type-ahead normally, and use the find dialog when it is brought forward.

It works fine for me on my Core Duo MacBook Pro. What kind of computer are you running. Please describe the computer and its setup.

Also when writing tickets please write from a neutral view, please do not insult the software, that is why it is BETA, it will have bugs, we are here to fix them.

Sorry; config info was accidentally cut as I was editing.

Not sure what you mean by insulting. I stated the prior behavior and the new, the problem I'm experiencing with the new, and suggested what areas needed improvement. Thought it was pretty reasonable, myself..

This problem is occuring on both Macs (config below). Please note that by "abysmally slow" I'm referring not only to the reflow speed but to the new laborious method. eg: two characters and hit return vs two characters, move hand to mouse, scroll around, wait for the scroll to finish, then double-click.

Also - I've now discovered that when all Contacts are being shown, the page down/up buttons no longer scrolls the window as one would expect. Hitting either reflows the window, but only to bring up the Find field then no further response.

My config:
300-MHz PowerMac G3 B&W w/ 640 MB RAM, OS X 10.4.11
800-MHz iBook G4 w/ 640 MB RAM, OS X 10.4.11
Accounts: 3 AIM, 2 ICQ, 2 GoogleTalk, 1 MSN, 3 Yahoo (related, so two are disabled).
Over 200 contacts.

Replying to darmok:

Sorry; config info was accidentally cut as I was editing. Not sure what you mean by insulting. I stated the prior behavior and the new, the problem I'm experiencing with the new, and suggested what areas needed improvement. Thought it was pretty reasonable, myself.. This problem is occuring on both Macs (config below). Please note that by "abysmally slow" I'm referring not only to the reflow speed but to the new laborious method. eg: two characters and hit return vs two characters, move hand to mouse, scroll around, wait for the scroll to finish, then double-click. Also - I've now discovered that when all Contacts are being shown, the page down/up buttons no longer scrolls the window as one would expect. Hitting either reflows the window, but only to bring up the Find field then no further response. My config:
300-MHz PowerMac G3 B&W w/ 640 MB RAM, OS X 10.4.11
800-MHz iBook G4 w/ 640 MB RAM, OS X 10.4.11
Accounts: 3 AIM, 2 ICQ, 2 GoogleTalk, 1 MSN, 3 Yahoo (related, so two are disabled).
Over 200 contacts.

Adium as it gets newer becomes more and more CPU intensive. the G3 seems like a slightly paltry config for this software. the G4 also seems slightly paltry. I suggest you try this out on a Leopard machine, if it works fine on leopard then there might be something up with your machine.

also i think the new method is easier. all the scrolling around and double clicking was not easy... this i type in a few chars and its done...

over 200 contacts on those configs COULD be causing issues. try making a new adium profile and adding just 20 contacts. if it works with that then your machine might be to blame

I'm pretty sure I know where the page up/down being caught incorrectly is in the code. That shouldn't behave as such. As for the "speed" of it, you can use the keyboard's up/down to navigate from the search field to the contact list to grab the contact quickly. The search won't refine enough to have a small list if you've got that many contacts, this is true. Like I said: it may be worth considering type-ahead by default, and the search bar when it's opened.

IMO, text-based instant messaging should not require a supercomputer to be usable. sigh. Religious argument. Ok...

Went poking around the prefs and found "animate changes" (prefs/advanced/contactlist). When it is *unchecked*, the list reflow as I type in the find field is quite fast / instantaneous. When it is *checked*, the reflow is very slow. On my Smurf, it's slow as expected (I guess) during normal window changes (show/hide all contacts, for example), but when that Find field is shown, it's much much slower. Obviously, I can and will avoid this speed issue by leaving "animate changes" unchecked. But it would seem to me that the reflow should occur at the same speed, regardless of the presence of that find field. Um... Perhaps the speed problem could be reduced if it didn't reflow the window for *every* character typed into that field? Perhaps, like Finder, type a few chars fast and it does only one redraw.

re over 200 contacts. Yes, reducing the number of contacts fixes the speed problem in that there's that much less window to draw. But hey, it's only a 17" crt. LOL

re using keyboard up/down arrow. My impression was that you had to mouse-click to get out of the find field. I see now that the arrow key does work, but if I hit it while the reflow is occurring or too soon thereafter, the key stroke is lost. Back to the type-ahead problem?

And thank you for your patience with all this. I realize I'm pushing the performance boundries by using such an old system. ... It has its pros and cons...

- Dan.

List drawing has some room for optimization last I checked (unnecessary malloc()s in drawRect for example). The really key bit would be to create something that automatically filters and unfilters the list rapidly so that it can be sharked properly.

Replying to darmok:

IMO, text-based instant messaging should not require a supercomputer to be usable. sigh. Religious argument. Ok... Went poking around the prefs and found "animate changes" (prefs/advanced/contactlist). When it is *unchecked*, the list reflow as I type in the find field is quite fast / instantaneous. When it is *checked*, the reflow is very slow. On my Smurf, it's slow as expected (I guess) during normal window changes (show/hide all contacts, for example), but when that Find field is shown, it's much much slower. Obviously, I can and will avoid this speed issue by leaving "animate changes" unchecked. But it would seem to me that the reflow should occur at the same speed, regardless of the presence of that find field. Um... Perhaps the speed problem could be reduced if it didn't reflow the window for *every* character typed into that field? Perhaps, like Finder, type a few chars fast and it does only one redraw. re over 200 contacts. Yes, reducing the number of contacts fixes the speed problem in that there's that much less window to draw. But hey, it's only a 17" crt. LOL re using keyboard up/down arrow. My impression was that you had to mouse-click to get out of the find field. I see now that the arrow key does work, but if I hit it while the reflow is occurring or too soon thereafter, the key stroke is lost. Back to the type-ahead problem? And thank you for your patience with all this. I realize I'm pushing the performance boundries by using such an old system. ... It has its pros and cons... - Dan.

todays computers are no super computers... but it is nice when older machines are kept in the support chain...

i believe that your computers graphics card may be over stressed possibly... since reducing the number of contacts fixes the problem...

so it is definitely a drawing issue...

possibly even a drawing bug...

alin0s: the gpu is not used for Adium's contact list animation.

More generally, guessing about performance issues is a very bad idea. Testing with a profiler is the only way to be sure.

Rather than focusing on optimization techniques that may or may not get done, why don't we just do the obvious to fix this. Could we not just disable animation in the same way that it is done when the check box in advanced preferences is unchecked while completing a search?

On my MBP I see no difference between having that checked or not while doing a search, so it's not like it loses any visual appeal. This way we can accomodate those with slower CPU's while at the same time only requiring a small amount of work to be done (assumably) compared to contact list rendering optimizations.

That seems like a rather sane optimization to me, although I still think it could use sharking :P

I agree strongly with jas about disabling animation during the search... and that with catfish_man that it could use sharking :)

Hold on... we already disable animation when the filter bar is shown. We have since it was initially committed in [22859].

(In [24010]) Fix breakage of the contact list animating setting whenever an object's contact list preference (such as its expanded status!) changes. Fixes suppression of animation during list filtering. Fixes #10135

For the record, while I found the previous implementation without disabling animation completely acceptable on my 2.33 ghz core II duo, I can tell that with [24010] searching is snappier. Thanks for the careful testing, Dan.

I still see a noticeable hesitation on the first character or two. Shark indicates that 18.8% (!!) is spent in objc_msgSend.

Catfish_Man: I can see this as well, but only on the first character, and it's still less than 1 second in length. I do have a large number of contacts to search through, and I would assume the length of the delay is dependent on that vs CPU power.

http://dscoder.com/menurebuildlag.png <-- we should be able to speed up 40% or so if we defer rebuilding the contact menu on sort

OK, Zac and I discussed this and I believe the correct fix is to make sortContactList aware of delayed notifications for list objects. I'll investigate this and implement it if correct on the bus this evening.

I'm wrong. The sortContactList calls are coming *from* delayed list updating. We'll need to investigate deferring menu building in some other way. Maybe stick it on a half second delay from the last sort.

This speeds things up massively, but it's also conceptually Wrong as Peter points out. We shouldn't be updating the menu at all, there's no reason to. I'm just not sure how to implement that.

Index: Frameworks/Adium Framework/Source/AIContactMenu.h
===================================================================
--- Frameworks/Adium Framework/Source/AIContactMenu.h	(revision 24010)
+++ Frameworks/Adium Framework/Source/AIContactMenu.h	(working copy)
@@ -13,6 +13,9 @@
 @interface AIContactMenu : AIAbstractListObjectMenu <AIListObjectObserver> {
 	AIListObject			*containingObject;
 	
+	//Rebuilds in response to sorting are deferred half a second to avoid blocking the UI (particularly when using list searching)
+	NSTimer					*coalesceTimer;
+	
 	id						delegate;
 	BOOL					delegateRespondsToDidSelectContact;
 	BOOL					delegateRespondsToShouldIncludeContact;	
Index: Frameworks/Adium Framework/Source/AIContactMenu.m
===================================================================
--- Frameworks/Adium Framework/Source/AIContactMenu.m	(revision 24010)
+++ Frameworks/Adium Framework/Source/AIContactMenu.m	(working copy)
@@ -85,7 +85,14 @@
 {
 	AIListObject *changedObject = [notification object];
 	if (changedObject == containingObject) {
-		[self rebuildMenu];
+		if(coalesceTimer)
+			[coalesceTimer invalidate];
+		
+		coalesceTimer = [[NSTimer scheduledTimerWithTimeInterval:0.5
+														  target:self
+														selector:@selector(rebuildMenu:)
+														userInfo:nil
+														 repeats:NO] retain];
 	}
 }
 
@@ -136,8 +143,16 @@
 								 [delegate contactMenuShouldDisplayGroupHeaders:self]);
 	
 	[delegate contactMenu:self didRebuildMenuItems:[self menuItems]];
-}	
+}
 
+//For coalesced rebuilds
+- (void) rebuildMenu:(NSTimer *)timer
+{
+	[self rebuildMenu];
+	[coalesceTimer release]; 
+	coalesceTimer = nil;
+}
+
 /*!
  * @brief Inform our delegate of menu selections
  */

Digging further, this is a regression from http://trac.adiumx.com/changeset/22570, which introduced the update-on-sort

Erm, not it's not. It was even worse before then. Very sorry for the bugspam!

New patch. This tells AIContactMenu to not update in response to sorting if it's the root contact list (AIContactMenu represents this as a nil containgObject). This seems to be safe to me, since a) it's the root. It itself can't get sorted somewhere else, and b) AIContactMenu does its own sorting, so it shouldn't care about the ordering of its contents, merely their existence/visibility/status. I'm not completely convinced I'm not missing something though, hence posting here instead of committing it.

Index: Frameworks/Adium Framework/Source/AIContactMenu.m
===================================================================
--- Frameworks/Adium Framework/Source/AIContactMenu.m	(revision 24010)
+++ Frameworks/Adium Framework/Source/AIContactMenu.m	(working copy)
@@ -84,7 +84,7 @@
 - (void)contactOrderChanged:(NSNotification *)notification
 {
 	AIListObject *changedObject = [notification object];
-	if (changedObject == containingObject) {
+	if (changedObject && changedObject == containingObject) {
 		[self rebuildMenu];
 	}
 }
@@ -136,7 +136,7 @@
 								 [delegate contactMenuShouldDisplayGroupHeaders:self]);
 	
 	[delegate contactMenu:self didRebuildMenuItems:[self menuItems]];
-}	
+}
 
 /*!
  * @brief Inform our delegate of menu selections

(In [24028]) Avoid rebuilding the contact menu unnecessarily. Refs #10135. Please test the menubar duck heavily after this change, as I am not 100% certain of its correctness

Wow! In 1.3b5, The Duck is snappy now! Thanks!!!!