All times are UTC.
00:01:59 * flo1 will try to do his best to never answer a "question" from DGMurdockIII that doesn't end with a question mark. 00:02:20 <DGMurdockIII> hu 00:14:08 --> flo-retina has joined #instantbird 00:14:09 * ChanServ sets mode +qo flo-retina flo-retina 00:14:19 <flo-retina> https://bugzilla.instantbird.org/attachment.cgi?id=2155 isn't in utf8 :( 00:35:10 <-- meh has quit (Quit: The point is: don't lose your dinosaur.) 01:05:47 <flo-retina> our shutdown isn't clean at all with JS-XMPP accounts currently (here's an example with a facebook account: http://pastebin.instantbird.com/114477) 01:05:55 <flo-retina> we probably regressed something recently :( 01:06:23 <flo-retina> as it seems we attempt to reconnect immediately after being disconnected 01:06:41 <flo-retina> hmm, could it be that we don't set the status to offline during shutdown? 01:09:57 <instantbot> florian@instantbird.org granted review for attachment 2167 on bug 1606. 01:10:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1606 nor, --, ---, clokep, ASSI, Update to Mozilla 17 01:10:07 <instantbot> florian@instantbird.org granted review for attachment 2169 on bug 1606. 01:10:44 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/565b27cbc394 - Patrick Cloke - Bug 1606 - Update to Mozilla 17, patches part, r=fqueze. 01:10:45 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/324662e782b9 - Florian Quèze - Bug 1606 - Update to Mozilla 17, purplexpcom part, r=clokep. 01:10:46 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/095bfb831be7 - Patrick Cloke - Bug 1606, Update to Mozilla 17, port bug 780357, bug 781446, bug 705532, r=fqueze. 01:14:52 <-- Optimizer has quit (Ping timeout) 01:18:03 --> Optimizer has joined #instantbird 01:50:54 <instant-buildbot> build #336 of macosx-onCommit is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-onCommit/builds/336 02:21:45 <-- rosonline has quit (Client exited) 02:30:42 <-- deltafalcon has quit (Ping timeout) 02:33:24 --> deltafalcon has joined #instantbird 03:05:31 --> Kaishi has joined #instantbird 03:25:17 <-- deltafalcon has quit (Ping timeout) 03:28:49 --> deltafalcon has joined #instantbird 03:58:02 <-- deltafalcon has quit (Ping timeout) 04:01:49 --> deltafalcon has joined #instantbird 04:28:52 <instant-buildbot> build #715 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/715 05:36:47 <-- deltafalcon has quit (Connection reset by peer) 05:40:00 --> deltafalcon has joined #instantbird 06:25:26 --> clokep has joined #instantbird 06:25:26 * ChanServ sets mode +o clokep 06:30:31 <instantbot> clokep@gmail.com set the Resolution field on bug 1606 to FIXED. 06:30:34 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1606 nor, --, 1.4, clokep, RESO FIXED, Update to Mozilla 17 06:56:10 <-- clokep has quit (Connection reset by peer) 07:04:45 <-- Optimizer has quit (Ping timeout) 07:08:28 --> Optimizer has joined #instantbird 07:21:01 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.89 [Firefox 20.0a1/20121209040202]) 07:36:11 --> jb has joined #instantbird 07:43:54 <-- jb has quit (Ping timeout) 07:46:08 <-- Optimizer has quit (Ping timeout) 07:47:35 --> jb has joined #instantbird 07:50:23 --> Optimizer has joined #instantbird 08:42:34 --> Lamaresh has joined #instantbird 08:44:33 <instantbot> New Core - XMPP bug 1856 filed by sztanpet@gmail.com. 08:44:35 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1856 nor, --, ---, nobody, UNCO, Crash when disconnecting from MSN/GTalk 08:46:05 <-- Lamaresh has left #instantbird () 08:47:52 <-- Optimizer has quit (Ping timeout) 08:51:14 --> Optimizer has joined #instantbird 08:53:44 <-- jb has quit (Ping timeout) 09:01:47 --> jb has joined #instantbird 10:07:45 <-- jb has quit (Ping timeout) 10:38:14 --> mpmc has joined #instantbird 10:45:57 --> rosonline has joined #instantbird 11:01:17 <-- Optimizer has quit (Ping timeout) 11:04:45 --> Optimizer has joined #instantbird 11:10:00 <-- Optimizer has quit (Ping timeout) 11:13:29 --> Optimizer has joined #instantbird 11:19:44 <-- mpmc has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com) 11:19:49 --> mpmc has joined #instantbird 11:45:28 --> jb has joined #instantbird 12:02:49 <-- rosonline has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com) 12:13:18 <-- jb has quit (Ping timeout) 12:14:43 <-- deltafalcon has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com) 12:36:30 --> meh has joined #instantbird 13:36:33 --> jb has joined #instantbird 13:39:53 <-- Optimizer has quit (Ping timeout) 13:43:09 --> Optimizer has joined #instantbird 13:50:03 <-- Optimizer has quit (Ping timeout) 13:54:07 --> Optimizer has joined #instantbird 13:54:54 <-- jb has quit (Ping timeout) 14:10:17 --> qlum has joined #instantbird 14:43:49 --> clokep has joined #instantbird 14:43:49 * ChanServ sets mode +o clokep 15:05:22 <-- Optimizer has quit (Ping timeout) 15:05:30 --> Optimizer has joined #instantbird 15:22:46 <-- Optimizer has quit (Ping timeout) 15:26:08 --> Optimizer has joined #instantbird 15:55:08 <-- Optimizer has quit (Ping timeout) 15:58:30 --> Optimizer has joined #instantbird 16:08:16 --> rosonline has joined #instantbird 16:45:51 <-- Optimizer has quit (Ping timeout) 16:49:02 --> Optimizer has joined #instantbird 17:16:41 <-- Optimizer has quit (Ping timeout) 17:19:57 --> Optimizer has joined #instantbird 17:34:44 <-- flo-retina has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com) 17:34:47 --> flo-retina has joined #instantbird 17:34:47 * ChanServ sets mode +qo flo-retina flo-retina 17:35:44 --> flo-reti1 has joined #instantbird 17:36:26 <flo-reti1> I get this error when I enabled the profiler add-on: http://pastebin.instantbird.com/114822 :-/ 17:36:36 <-- flo-retina has quit (Ping timeout) 17:44:52 * flo-reti1 wonders what needs to be done to have resource://services-common/ 17:45:33 <clokep> Are you including that xpt file that aleth found or whatever it was? 17:45:39 <flo-reti1> hmm http://mxr.mozilla.org/comm-central/source/mozilla/services/sync/SyncComponents.manifest#26 17:47:38 <clokep> http://log.bezut.info/instantbird/121207/#m250 17:48:12 <clokep> Apparently http://mxr.mozilla.org/comm-central/source/mail/installer/package-manifest.in#505 17:48:27 * clokep stops talking about thins he doesn't know about. ;) 17:48:42 <clokep> Also, I've been hanging every Instantbird shutdown. :( 17:48:46 <clokep> For a few days now. 17:48:55 <flo-reti1> and now I get "Error: geckoprofiler: An exception occurred: File "resource://gre/modules/osfile.jsm", line 12, in throw new Error("osfile.jsm cannot be used from the main thread yet"); 17:49:27 <-- clokep has quit (Connection reset by peer) 17:50:00 --> jb has joined #instantbird 17:50:09 <flo-reti1> clokep: interestingly, the nsIProfiler interface is already there in current Instantbird nightlies, even without adding more xpt files, so maybe they are already linked together somewhere else in toolkit... 17:50:34 <flo-reti1> unrelated, I'm curious to how "flo-retina" became "flo-reti1". Where did the "n" go? :-S 17:54:02 <-- jb has quit (Ping timeout) 17:57:41 <flo-reti1> pfff, the add-on sdk has a built-in list of application ids it can work with, and throws if using an application that isn't known 17:57:46 <flo-reti1> what a piece of c... :( 17:58:00 --> jb has joined #instantbird 18:15:58 <-- jb has quit (Ping timeout) 18:34:42 <-- mpmc has quit (Connection reset by peer) 18:36:43 --> mpmc has joined #instantbird 18:47:25 <flo-reti1> http://people.mozilla.com/~bgirard/cleopatra/?1355682365811#report=e1dc014fba4572a1e23585874ddd5b9a4fae54df here is a profile of joining #ubuntu 18:48:12 <flo-reti1> It's done from a debug build, so the performance data may not be completely relevant; I'm more pasting this so that we can start looking at a profile from Instantbird to see if they look usable 18:57:50 --> mconley has joined #instantbird 19:04:14 * flo-reti1 is rebuilding with --enable-profiling 19:04:22 <flo-reti1> (a non debug build) 19:12:08 --> aleth has joined #instantbird 19:12:09 * ChanServ sets mode +h aleth 19:13:39 <flo-reti1> so the things we want to profile are: 1. joining #ubuntu, 2. Displaying a large conv on hold. 3. displaying offline buddies. right? :) 19:23:04 <flo-reti1> aleth: a profile of displaying the nicklist after joining #ubuntu: http://people.mozilla.com/~bgirard/cleopatra/#report=51358fa444c83fbfce7448642d04f60c0de8b292 19:25:09 <aleth> flo-reti1: you got the profiler working! :) 19:25:13 <aleth> excellent 19:25:20 <flo-reti1> not fully working 19:25:31 <flo-reti1> but enough to extract profiles with a few hacks 19:26:00 <flo-reti1> for some reason I haven't managed to get to the profile window :( 19:26:05 <flo-reti1> so I dump to the terminal the profile data 19:26:13 <flo-reti1> and then paste it in the web UI 19:26:27 <flo-reti1> (that's slow, but I couldn't wait to look at the first data :)) 19:26:40 <aleth> still, almost there :) 19:26:56 * aleth wonders who made you flo-reti1 19:27:00 <aleth> not our code I think 19:27:29 <flo-reti1> aleth: flo-retina was already connected 19:27:30 <aleth> Sounds like the moz17 update happened, I should update ;) 19:27:36 <flo-reti1> I would be curious to know how the "na" disappeared 19:27:49 <aleth> Our code would make it flo-retina1 19:28:08 <aleth> So was it the server? 19:28:36 <flo-reti1> aleth: so the first surprise for me when looking at that profile is that almost 18% of the time is spent in the QueryInterface method of chat buddies 19:28:46 <aleth> flo-reti1: Ditto 19:29:36 <aleth> Well, at first glance I was pleased that listbox DOM methods are down a lot as intended 19:29:43 <flo-reti1> so 2 possible things to look at: 1. Check if it's called several time per buddy and if it is, why. 2. Optimize that implementation for the irc chat buddies 19:31:57 <flo-reti1> we waste 1.8% of the time doing QI calls at http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/widgets/listbox.xml#687 19:32:50 <aleth> every listbox XUL method will probably use it 19:33:41 <aleth> Is the enumerator interface slow? 19:33:45 <flo-reti1> wait, I uploaded only the JS 19:33:50 <flo-reti1> let me reupload 19:34:11 <flo-reti1> http://people.mozilla.com/~bgirard/cleopatra/#report=d0dd22eca242909e503c653bc0a581fc79beafce should be more useful 19:40:04 <flo-reti1> I don't see why the enumerator would be slow 19:40:32 <flo-reti1> but each time we get an item from it, we likely call QueryInterface and then getInterfaces on the result. 19:40:53 <flo-reti1> it's also possible that we are wasting a lot of time with cross compartment wrappers 19:41:12 <aleth> the question is, can we find out with the profiler ;) 19:41:27 <flo-reti1> (especially when the prototype chain of an object comes from objects initially created in various JS modules) 19:41:29 * aleth still not totally comfortable with the interface 19:42:05 <flo-reti1> I think we should start by investigating the QueryInterface call patterns 19:51:05 --> EionRobb has joined #instantbird 19:52:28 <-- rosonline has quit (Ping timeout) 19:57:38 --> rosonline has joined #instantbird 20:10:36 --> jb has joined #instantbird 20:10:41 <-- aleth has quit (Quit: Au revoir) 20:10:50 --> aleth has joined #instantbird 20:10:51 * ChanServ sets mode +h aleth 20:12:32 <aleth> Is there any rule to when we use doxygen style comments btw? 20:18:18 <-- jb has quit (Ping timeout) 20:23:30 <-- rosonline has quit (Ping timeout) 20:31:40 <aleth> Looks like there was no Linux nightly 21:04:31 <-- mconley has quit (Input/output error) 21:11:44 <aleth> For future reference: the main QueryInterface calls seem to be the ones here http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1677 and similarly here http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1597 21:18:18 <-- Optimizer has quit (Ping timeout) 21:21:59 --> Optimizer has joined #instantbird 21:58:03 <-- Cam has quit (Ping timeout) 21:59:40 <-- Optimizer has quit (Ping timeout) 22:02:50 --> Optimizer has joined #instantbird 22:08:08 --> Cam has joined #instantbird 22:08:52 <-- aleth has quit (Ping timeout) 22:12:13 --> aleth has joined #instantbird 22:12:14 * ChanServ sets mode +h aleth 22:20:12 --> DGMurdockIII has joined #instantbird 22:24:35 <-- aleth has quit (Ping timeout) 22:27:52 --> aleth has joined #instantbird 22:27:52 * ChanServ sets mode +h aleth 22:29:05 <flo1> QI on the enumerator shouldn't be too expensive (we don't have that many enumerators, right?) 22:30:55 <aleth> It's just that if I'm reading it right, those are the QI calls that happen 22:31:27 <aleth> I always thought an enumerator wrapper was pretty lightweight 22:31:33 <aleth> but I don't really know... 22:33:38 <flo1> aleth: there are hidden QI calls 22:33:57 <flo1> aleth: I suspect each time we cross the xpconnect barrier each objected is QI'ed into nsISupports 22:34:41 <flo1> and then into nsIClassInfo, and if that call succeeds, there's then a getInterfaces call, that may be followed by a QI for each of the returned interfaces 22:34:52 <flo1> let's see if I can find some documentation about this 22:35:55 <flo1> https://developer.mozilla.org/en-US/docs/Mozilla_DOM_Hacking_Guide#Interface_flattening 22:36:48 <aleth> Hmm 22:37:39 <aleth> The only implicit XPCOM object there is the listbox though, and those calls should be identifiable separately? 22:37:51 <flo-reti1> in the previous profile, 1.5% of the time is in getInterfaces 22:38:05 <flo-reti1> what do you mean by "implicit"? 22:39:10 <aleth> The enumerator QI calls are explicitly there in the code, and you're not suspecting those? 22:39:28 <flo-reti1> aleth: our nsSimpleEnumerator object doesn't implement nsIClassInfo, and uses XPCOMUtils (not imXPCOMUtils) for QI, see http://lxr.instantbird.org/instantbird/source/chat/modules/imXPCOMUtils.jsm#248 22:39:52 <flo-reti1> in the profile we see QI calls for a QI implemented in XPCOMUtils. They are 0.2% of the total profile. 22:40:14 <flo-reti1> aleth: I'm not suspecting them because they are explicitly listed as 0.2% of the time in the profile 22:40:52 <flo-reti1> wait, they are on 2 other lines in the profile, with 0.1% each. So that's 0.4% of the total 22:42:04 <aleth> ah right, no nsIClassInfo for those. 22:43:45 <flo-reti1> ah, clicking the "Invert callstack" option is interesting :) 22:44:45 <-- aleth has quit (Ping timeout) 22:44:49 <flo-reti1> it says we are spending 16.4% of the total time at http://lxr.instantbird.org/instantbird/source/chat/modules/imXPCOMUtils.jsm#190 22:49:51 <flo-reti1> 6.8% is in QI calls made by http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1170 22:53:27 --> aleth has joined #instantbird 22:53:27 * ChanServ sets mode +h aleth 22:53:47 <flo-reti1> so I suspect http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1679 QIs into nsISupports and maybe nsIClassInfo, and http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1175 QIs into prplIAccountBuddy when accessing the "name" attribute 22:54:21 <aleth> This machine is very crashy today for some reason :( 22:54:34 * aleth suspects the nvidia driver 22:55:03 <flo-reti1> and I suspect the observe() and addBuddy() methods are actually blamed for time spent in the C++ xpconnect code that leads to the QI call (QI is blamed by the profiler only once we are actually inside the JS QI implementation) 22:55:04 <instantbot> c++ is e-- ah, nevermind. 22:55:33 <aleth> oh, that's interesting 22:56:14 <flo-reti1> I suspect removing the nsIClassInfo implementation and QI'ing explicitly into prplIConvChatBuddy could save a lot of time 22:56:43 <aleth> Right. 22:56:51 <flo-reti1> but maybe we can do even better 22:56:56 <aleth> We could even check if we need to keep the prplIConvChatBuddy at all 22:57:42 <aleth> or if we can fetch it lazily when needed 22:58:11 <flo-reti1> aleth: do you remember if the bug about using nsISimpleEnumerator in notifications being idiotic was filed in BIO or BMO? 22:58:31 <flo-reti1> I think we could just fix that bug 22:58:45 <flo-reti1> it would make us create a new interface for the list of added chat buddies 22:59:03 <flo-reti1> and that "list" would just return a JS array of explicitly typed xpcom components 23:00:27 <flo-reti1> so the 2 ways to speed this up are to reduce the total count of QI calls, and to reduce the time each call takes (removing the things that are across compartments, the array.some function call, ...). 23:00:33 <aleth> I've never seen that bug, so it must have been BMO? 23:00:44 <flo-reti1> I'm sure we can save a significant amount of time by just optimizing that QI mess 23:00:54 <flo-reti1> aleth: I only remember that Mook mentioned it 23:01:29 <aleth> I wonder if we shouldn't just move the whole "list" to the imAccount anyway. 23:01:54 <flo-reti1> aleth: the basic idea of that bug was that the enumarator can only be enumerated once. So if we have 2 listeners for that chat-buddy-add notification (eg because the conversation is displayed in 2 different windows), we are screwed 23:02:00 <aleth> Of course that's a separate problem 23:02:05 <flo-reti1> (or really, if any add-on listens for that notification) 23:02:29 <-- flo1 has quit (Ping timeout) 23:03:04 <flo-reti1> aleth: I don't think this is the getParticipant call, it's the enumerators from the chat-buddy-add notification. 23:03:07 <aleth> We would have to check that, but I doubt it needs to be used twice, unless we want to support multiple conv bindings per conversation in the future (eg for an "IB server" that serves multiple "UI clients" on various machines) 23:03:10 <flo-reti1> (in my profile I mean.) 23:03:24 <flo-reti1> (it's likely that in the getParticipant case we are doing as many stupid QI calls) 23:03:36 <aleth> flo-reti1: The implementation is pretty much the same 23:04:04 <aleth> And for large nicklists, only a part will be ready for the getParticipant call 23:04:15 <flo-reti1> aleth: well, if add-ons should never attempt to use these notifications, we should document it ;) 23:04:27 <aleth> Are they documented anywhere? ;) 23:04:41 <flo-reti1> likely in the idl file and on the wiki 23:04:47 <flo-reti1> ok, time to profile a large conv on hold, right? ;) 23:04:58 <flo-reti1> hmm 23:05:07 <aleth> That would simplify the profile 23:05:20 <flo-reti1> my usual testcase for that is watching a stupid twitter keyword, but that also creates a large nick list :-/ 23:05:53 <flo-reti1> aleth: oh, I meant "time to profile the display of messages" 23:06:42 <flo-reti1> is BMO down? :( 23:07:24 <aleth> Looks like it :( 23:07:32 <aleth> "Invert callstack" is nice :) 23:08:41 <flo-reti1> I can't find the bug, even on my gmail bugzilla label 23:08:49 <flo-reti1> so it was probably just discussed over IRC 23:09:58 <flo-reti1> aleth: wouldn't a tab completion or nick coloring add-on be interested in the chat-buddy-add notification? (assuming we didn't have these features yet) 23:10:40 <aleth> The cost of accessing aBuddy.name is really interesting, I would not have thought of that at all. 23:10:58 <aleth> flo-reti1: we had add-ons for both of those and they managed without? 23:11:22 <flo-reti1> aarg, I missed the "cd" in the command I used to go to the non-debug obj dir :( 23:11:31 <aleth> But I agree it's not nice for any notification to be read-once. 23:11:32 <flo-reti1> so the profile we looked at was from the debug build too :( 23:11:45 <flo-reti1> aleth: they were doing horrible hacks inside the conversation binding 23:12:01 <aleth> There should be a way to get the best of both worlds. 23:12:23 <flo-reti1> aleth: well, the cost is not for accessing aBuddy.name, it's for the first attribute access 23:12:39 <flo-reti1> if you access it a second time, it won't be twice as expensive 23:12:43 <aleth> The first access within a given function, or in general? 23:13:12 <flo-reti1> the first access on that side of the xpconnect wrapper 23:13:35 <aleth> flo-reti1: How about a notification that contains no data, and then the listener picks up the array from the account? 23:13:48 <flo-reti1> I'm going to do that profile again on the non-debug build 23:13:50 * aleth still wondering whether putting the list in the imAccount would solve both issues 23:13:56 <flo-reti1> it's possible the QI will be much less visible 23:14:14 <flo-reti1> aleth: the nicks we need are the *new* nicks 23:14:25 <flo-reti1> aleth: we don't want the whole participant list each time one person joins 23:14:29 <aleth> Sure 23:15:22 <aleth> Well, I have no idea atm that isn't ugly in some way either 23:16:01 <flo-reti1> aleth: with the non-debug build my UI doesn't even freeze when joining #ubuntu 23:16:29 <aleth> Nor does mine, since the speedup patch landed ;) 23:16:40 <aleth> but that's on a fast machine... 23:17:42 <flo-reti1> aleth: ok, we haven't wasted our time 23:17:55 <flo-reti1> my machine is a little bit too fast for the non-debug build, but the data is similar 23:17:59 <aleth> It's still about half a second for me 23:18:20 <flo-reti1> QI is still 16% of the total time 23:18:22 <aleth> But I suspect most of that time is not the nicklist 23:18:47 <flo-reti1> it was 422ms for me ;) 23:19:04 <aleth> great, so the debug build doesnt distort too much:) 23:19:07 <aleth> sorry, gtg 23:19:16 <-- aleth has quit (Input/output error) 23:21:59 <flo-reti1> http://people.mozilla.com/~bgirard/cleopatra/#report=b5ee6fb95f810680da99191a8b2e0919ba744b1b is the non debug profile 23:25:32 <-- DGMurdockIII has quit (Ping timeout) 23:25:55 --> DGMurdockIII has joined #instantbird 23:36:37 --> jb has joined #instantbird 23:39:31 <flo-reti1> here is a profile of watching the "a" keyword on twitter: http://people.mozilla.com/~bgirard/cleopatra/#report=08fd44abd0970bdb6dd40dbde5cbbee528180d79 23:40:20 <flo-reti1> a third of the time is spent in Show Nick's get regexp function at http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1327 23:42:00 <flo-reti1> 48% of the rest is in http://mxr.mozilla.org/comm-central/source/chat/protocols/twitter/twitter.js#325, ie adding chat buddies one by one (can't we at least batch that? + there's the same QI mess as for IRC...) 23:47:40 --> Mic has joined #instantbird 23:47:40 * ChanServ sets mode +h Mic 23:47:51 <flo-reti1> and 10.6% is in _activateBuddy (but only 1.9 in that are related to the color). 23:49:39 <flo-reti1> Things that are expensive in _activateBuddy are the setTimeout calls (56%), the clearTimeout (8.5%), removeAttribute (9.4% that's causing XBL/CSS changes so it's expected that it takes time) 23:51:44 <flo-reti1> _setBuddyColor is 18.3% of _activateBuddy. 11.1% is the setAttribute call with the resulting color; we waste time setting the attribute on the DOM node, and it's then parsed by the CSS parser. Using .style.color may be faster. 23:57:02 <-- jb has quit (Ping timeout)