#instantbird log on 12 16 2012

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)