Performance issues with a massive amount of tabs
Steps to reproduce
This one's going to be a little difficult to reproduce in general, so instead I'll talk about what my typical scenario works like.
I use a lot of tabs. I currently have ~11k tabs open in this FF profile, spread across 34 windows. Most tabs are unloaded since the restart, but I'll also open a lot of tabs during a session. My sessions are long lived (2 weeks+, usually over a month).
I've noticed that sidebery will get into this low-performance state where it makes all of FF very sluggish. Turning the sidebar off (by clicking the toolbar icon), and the on again (by clicking it again) usually fixes that (*).
I've noticed this has to do with how many tabs are open and loaded. Or maybe, and it's just an idea, maybe it has to do with the amount of tabs I've visited since the sidebery sidebar got loaded (**) (which is usually at startup, or when i do the reload as above (*).
I've also noticed that this happens more the longer I have FF open, but again this might have to do with the current state accumulated by sidebery (**).
I've also noticed this can be dependent on the window.
So for example, I'll usually have a lot of YT tabs open and loaded in a single window I use to open YT tabs. Switching tabs in that window can be super sluggish, I mean several seconds for the tab to open in the FF tab bar, longer (10+ seconds) for the new tab to even show up in sidebery with just the url as the title (not even the real title loaded yet), and then even longer to load (***). But if I open a new window, browsing around in there, opening new tabs, etc is pretty snappy. However, if at that point, in the new window, which has e.g. 5 tabs, I try to open a youtube tab, then that becomes super sluggish again.
So it's like there's some sort of separation of execution, almost like a separate thread of the addon for the new window, but when I open a tab on a domain that's open somewhere else already, it's like it has to start sharing state / computation with the existing sluggish window.
Again, when it's in this state, and I do the "restart" as in (*) above, it's fine again. For a while, after which it's not fine again.
I know it can be daunting to figure out why this is happening so I don't expect an immediate fix. But I would really appreciate it if you could look into this, and I can try and help figure things out as well if I can, I'm a programmer myself and sidebery is one of my main productivity tools.
Some other things that happen when sidebery is in "sluggish mode":
- web requests are really slow to actuate, but not to load once they do. So eg if I open the notification bell popup menu in youtube, then it'll have some of the notifications loaded. If I scroll down, it'll only have the text (or even just placeholders) loaded. Then it sits around for a bit and then loads everything instantly. If I have another youtube tab loading at the same time like in (***) then the notifications will not load until only after the tabs have loaded.
- right click menu will be super slow. A "restart" (*) fixes it also.
- I've noticed that having gmail open for a while also messes with sidebery, and I've had it on auto-reload for a while. So maybe that's the culprit, and not the amount of tabs. I don't have a lot of live gmail tabs open, usually only about 5-10.
- opening a url by typing things into the address bar has a race condition. So if I type something in, and press enter immediately when I'm done typing and I don't wait for the auto suggestions to load, then it will only load as if I'd only typed part of what I really typed in, and I think what it loads is the string it last loaded suggestions for. So let's say I type in "apple pie recipes online quick" and press enter, it might only search google for "applie pie reci". The same goes for when typing in full URLs.
- switching tabs (ctrl+pgdn/pgup) is super sluggish too, as is ctrl+tab
- switching tabs by clicking on them in sidebery is way more sluggish than ctrl+pgdn/pgup and ctrl+tab
- closing windows that have a lot of live loaded tabs, or unloading all those tabs, helps the performance quite a bit, kind of like the restart procedure above (*) but sometimes to a lesser, and sometimes to a greater degree
It feels like sidebery might be accumulating a large working set as it operates. Is there perhaps a way to monitor that and ultimately curb it? It might be hidden from view due to the semantics of javascript - the js runtime might be doing things "behind the scenes" that you don't necessarily have the ability to know about from the sandboxed context of an addon.
This issue has existed for as long as I've been using sidebery, but I haven't really been able to put it in words quite well enough, so it's not something recently introduced.
Thank you for your time and thanks for reading.
Actual behavior
.
Expected behavior
in case you are unable to fix the root cause, maybe an functionality to unload specific domains after a specific time would be helpful. there doesn't exist an addon like that. i know FF auto-unloads tabs upon OOM, but things really have to get bad performance-wise for this to happen and it usually ends up with the OS being crashy.
System
Win 11 x64 pro
Firefox version
latest FF x64
Sidebery version
5.4.0.5
Logs
oh here's another thing, I use sidebery as "backup", so it dumps a json snapshot every 2 hours, so maybe some of that hangs around in the addon's state as well. The json files are currently around 2MB.