As I mentioned before, I’ve been a manager for a year. I’ve focused solely on paper pushing for the past 6 months. Even though I love programming, it’s surprisingly enjoyable to merely tell others what to do :) However, as all technical managers find out, eventually one gets very bored without doing something technical. So here it goes…
Why The Frick Are My Tabs So Damn Laggy?
****I noticed that tab switching has become unbearable lately. I finally filed a bug and with Gavin’s help investigated the brokenness. Turned out that we awesomely
1
| |
in the mousedown handler (bug 743877). This means that I click on my tab, only to suggest to the browser to schedule an event to be handled some time in the future. The browser will also go ahead and flush the existing event queue before getting to handling my event. I measured lag anywhere from 30 to 160+milliseconds before the browser even started handling my click.
This code is pretty ancient, why has tab switching gotten slow within the last few months? Turns out we now take a tab thumbnail on every tabselect, which takes >100ms on my machine… We then carefully use async IO to store that image in our network disk cache. Unfortunately our cache uses locks in creative ways effectively making that code path synchronous (723577, 723582, 722033, 722034). See 742594 for thumbnail jank. Naturally, all of the above + cycle collection + garbage collection + etc gets scheduled right in the middle of handling tab switching :)
Thanks to a strategically misplaced setTimeout, the browser currently can spend a very long time not responding to user input (seconds sometimes). I bet we have a quite a few places that “solve” problems with setTimeouts like above.
There is hope
See bug 743069 for some proof of concept patches on making tab switching more responsive. As far as I can see, there is no technical reason for us to not to have a buttery-smooth tab strip. Next steps are figuring out why XUL draws slowly, throttling other browser activity while interacting with tab strips, etc.