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 setTimeout(do_stuff, 0) 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.
You can add tab groups in the equation. Switching between groups is unbelievably slow when you have tons of tabs.
is that tab candy? I’m not too bothered by non-primary ui being slow?
These problems illustrate how Chrome can get/feel so speedy. They could look at how something should work(Firefox) but because it is new code they could avoid these old workarounds that were used in 2000.
@Ferdinand. Honestly this has nothing to do with old code. I think the difference is social.
I think we started snappy a bit late. We are learning from our mistakes and borrowing good ideas from chrome when we see them. Just like they did with us.
Seconding glandium’s comment. The slowness is particularly bad on selecting a tab in Panorama. Tab candy/Panorama is very much “primary UI” for me as it’s a very convenient way to switch tabs. (Also, the problem may have some of the same roots?)
Firefox wasting resources on tab switching by taking a thumbnail is the last straw for me in terms of this new tab page malarky. I do not give a shit about a new tab page!! I never use the new tab button since I have open-new-tabs-from-* set up. Stuff this new tab crap slowing down my experience. Firefox does enough of that already! Please tell me how to turn off this unwanted thumbnail-creation-on-tab-click behavior.
@pd. There is a bug filed for turning off tab screenshots: http://bugzil.la/726347.
Rest assured, we’ll fix this particular tab thumbnail perf issue.
To be perfectly honest, I’d probably just make the tab thumbnailing code run via a setTimeout(funcname, 0)… then it will run after the normal tab stuff, problem solved! >_> lol
I code JavaScript for a living btw, haha >_>
Well I’m glad that work is under way to make tab switching quicker,however I too wouldn’t dismiss the embarrassing delay when switching groups in Panorama/TabCandy as a non-primary ui issue,this feature has been with Firefox for a long time now,and,while undoubtedly useful and with a great potential,still to date doesn’t work as expected and promised from the beginning.
Maybe I have a different problem here. I am not sure. If I open http://www.escapistmagazine.com/videos/view/unskippable/1713-Deadly-Premonition-Part-1 , switch to a different tab, wait 30s and switch back it takes an exceptional large amount of time.
Taras,
Glad to see this issue getting attention. From looking at the changes made to the locking code, it appears that locks are being introduced where they are not needed.
Thanks for providing the links to the bugs so we can follow along as fixes are posted.
Manoj
@Manoh, please comment in bugs and refer to snippets of code in question. It’s not productive to say that here
kamulos, I can’t reproduce that. Have you tried turning off gfx acceleration?
Looks like a reviewer has made that comment already. The changes are in good hands (not that I doubted it)
Manoj
@tglek: It does have a delay for me even if I disable hardware acceleration. I can reproduce it more easily when I switch to about:memory, click minimize memory and switch back. Because the built-in profiler only outputs hex-adresses for me all I can show now is the output of about:jank:
31 – c-JS::CallEventHandler
I commented on it here – https://bugzilla.mozilla.org/show_bug.cgi?id=743069#c14