Having lots of tabs open slows done switch-to-tab. We currently iterate all tabs until we hit one with the right URL. As nsPlacesAutoComplete is updated per onLocationChange() notification we should probably do the same here and maintain a map that maps tabs to urls and offer gBrowser.switchToTabHavingURI() method that uses it?
Another possible approach would be to implement a getTabForURL that did a properly optimized search instead of brute force iteration over the set. It would probably be fast enough, and use less memory than creating a new in-memory cache.
We could go the way of bug 964349 and update URLs for tabs in onLocationChange(). We could probably use WeakRefs so that we don't need to listen for TabClose events. (In reply to Dietrich Ayala (:dietrich) from comment #1) > Another possible approach would be to implement a getTabForURL that did a > properly optimized search instead of brute force iteration over the set. Sorry, I'm not sure what you mean by doing a properly optimized search without using an in-memory cache? How would you go about that?
4 years have passed and I can still see this bug (I have 350 tabs currently) Please fix it, this is one of the most annoying bugs when browsing with many tabs. Shouldn't it be a marked as blocking of Bug 1337841 or Bug 1338595 (or other related meta bugs) ?
Something strange happened... Suddenly Nightly became very fast after it was rather slow: tab switching became immediate and very fast, before that it was very slow. but not only that, page loading and rendering became very fast too. before, it was somewhat slow, but not very slow like tab switching. The only changes that I can think of that I did are: 1. Restarted the computer because I had a firefox updater lock file in the Nightly directory that prevented updates, and I couldn't delete it because it was used by a process which was a hanged Firefox software updater process that I couldn't kill using task manager. 2. Then after the updater lock file was removed I updated from Nightly 59.0a1 (2018-01-01) to 59.0a1 (2018-01-02) Thus, I am not sure whether it was the Nightly update that improved tab switch time, or the computer restart (the removed the stuck Firefox updater process)? Was there any change/bugfix/commit in Firefox Nightly in this time frame that can explain the improvement in Nightly tab switch time? Or was it just some problem with my computer that caused it ?
Tab switch time is now back to being slow again. I think there was a regression from comment 4. It is slow not only with lots of tabs, but with a small number of tabs too. I tested it now on a clean profile with only one add-on (ublock-origin) , and only 4-5 tabs, and tab switch time is slow again. Pages load slower too . *) This bug is not tracked in any performance related meta-bug. Can someone please triage in which performance meta-bug does it belong ? Should it be marked as blocking Bug 1337841 (Quantum flow)? *) If there is telemetry data about tab switch time, can someone check to verify that there was a regression (after an improvement) in this time frame, to confirm my report?
(In reply to nivtwig from comment #5) > *) If there is telemetry data about tab switch time, can someone check to > verify that there was a regression (after an improvement) in this time > frame, to confirm my report? Which exact build were you experiencing the slowness in?
I can also see this now with the lastest Nightly 60.0a1 (2018-01-27) (64-bit), Build ID 20180127100319 The builds I used in comment 4 and comment 5, were most likely the latest builds at the time of posting the comment, but I am not 100% sure. If those were not the latest then probably one or 2 earlier builds, as I update often. Steps to reproduce - open only 6 tabs: Bug 967059, Bug 1426103, Bug 1427447, Bug 1384733, Bug 690229, and "about:support" Wait for the tabs to fully load, then click on the tab buttons randomly a lot of times. Note that this is not horribly slow (I guess it is less than 1 second, 300-500ms, but I am not sure), for some people it will not be noticeable, but it is slow enough to be noticeable and annoying for me, for example vs Google Chrome which has immediate tab switch. When you click the tab button, it takes a small time (although less than a second) to be highlighted as the active tab, and give the feedback to the user that it was clicked, so the tab switch is perceived as somewhat slow. Switching between the tabs using CTRL + TAB is also slower, and not immediate like with Google Chrome. I am not sure this is a regression from the Firefox release (58.0), but I think there was a regression in Nightly from the time of comment 4 (and even if there was no regression, tab switch time should be fixed...) Hardware: Dual core CPU E6700 3.2GHz, 6GB memory, Windows 10 64-bit, 240GB SanDisk SSD
This bug depends on Bug 1318939, please add as dependency. Bug 1318939 is about slow tab switch time which happens also in the case of a small number of tabs, and is probably a regression caused by e10s (multi-process Firefox) Disabling e10s fixes the slow tab switch time in the case of a small number of tabs (comment 7), and makes it immediate. In addition, even after disabling e10s, there is still slow tab switch time in the case of a lot of tabs, which is this bug.
(In reply to nivtwig from comment #8) I'm completely unable to reproduce the slowness you're describing using the steps you provided. My tab switches among those six tabs are immediate. nivtwig, since you're able to reproduce this consistently, can you try reproducing it in Safe Mode? (Help > Restart with Add-ons Disabled). Does that change the performance at all?
(In reply to Mike Conley (:mconley) (:⚙️) from comment #9) > (In reply to nivtwig from comment #8) > > I'm completely unable to reproduce the slowness you're describing using the > steps you provided. My tab switches among those six tabs are immediate. > > nivtwig, since you're able to reproduce this consistently, can you try > reproducing it in Safe Mode? (Help > Restart with Add-ons Disabled). Does > that change the performance at all? I answered in Bug 1318939 comment 17, where this discussion is more appropriate, since the current bug is about the case of many tabs.
You need to log in before you can comment on or make changes to this bug.