Here is a profile of it https://perfht.ml/2DnMujm showing that the richlistbox getItemAtIndex implementation is what's taking all the time here, with each call calling https://searchfox.org/mozilla-central/rev/490ab7f9b84570573a49d7fa018673ce0d5ddf22/toolkit/content/widgets/richlistbox.js#264-265 which is O(n).

I strongly suspect this of being a regression from bug 1475817 which switched from a listbox to a richlistbox. I don't remember this being particularly fast before, but currently it's outrageously slow (more than 5s to display the list of #ubuntu participants on an i9 macbook pro).

Doing .firstChild.nextSibling.getAttribute("value").toLowerCase() all the time at
https://searchfox.org/comm-central/rev/c5e9e71e6ab4b96868162a1687da42b47872fc2b/mail/components/im/content/imconversation.xml#1150-1151 must not be great either for performance.

I think the way forward is to keep an array of displayed nicks within the imconversation binding, and avoid touching the DOM to find the insertion position for new nicks.

(In reply to Florian Quèze [:florian] from comment #0)

...
I think the way forward is to keep an array of displayed nicks within the imconversation binding, and avoid touching the DOM to find the insertion position for new nicks.

Is this bad enough to be a blocker for version 68?

I don't know. Florian, was this fixed by bug 1526716 or is there more to do here?

(In reply to Patrick Cloke [:clokep] from comment #2)

Florian, was this fixed by bug 1526716 or is there more to do here?

Hopefully most of it was fixed there. I don't remember in details unfortunately. If someone captures a recent profile of it, feel free to needinfo me to have a look at it.