scrollbar.xml shows up consistently high in dtrace profiles. We create this binding far more often than you might expect, because iframes, selects, etc. require one. roc writes: I wonder how much our scrollbar implementation costs us. Each scrollbar instantiates an XBL binding which creates five anonymous elements, each of which gets a frame and has other overhead. Every <select> has one scrollbar, every <textarea> has two, every <iframe> and top-level document has two, and every overflow:auto element has two. It would be an interesting experiment to remove the XBL binding and see what difference that makes to Tp. I'll do it next time I need to play with Talos. If it's a significant improvement, we could build a specialized XUL element + frame combination that renders a native scrollbar.

FWIW roc's proposed change would massively help the mac scrollbar code. See bug 398137 and bug 385058 which could potentially be fixed by roc's changes. I'd like to see it for 1.9.

Noming since this is a perf improvement (and maybe a big one)

Would it be possible to attach some profiles here too? Or at least post some numbers, not just "high in dtrace profiles".

Comment on attachment 284685 [details] 10 loads of cnn.com That's pretty simple page, and it doesn't show the cost of creating the xbl.

Sayrer, did you do any testing here? Also, we should test after my fix for bug 384612 is in since that completely removes all scripts from scrollbars, and I think it should make us reflow less on mac as well.

Do we want to leave this bug open?

This is not something that we're going to block beta 2 for, but we do need to get it done. Being realistic here and moving to a P2. It's still on sayre's radar.

this won't make 1.9, moving off blocking list. renom if you disagree.