(It would be cool if dormant tabs can just hold the URL, and kill all memory requirements when dormant after N period of time..)
But heck, even when I am running a high-end game on my machine, the memory consumption is less than when I have a bunch of tabs open displaying mostly text ...
I had over 1000 tabs open in Firefox (macOS) and never noticed any problems. (Trying to clear them out. Down to 920 now.) 2.26 GB out of 32.00 GB is used by Firefox. I have about 70 open in Chrome (since only a certain number fit on the screen) and it's split across 12 processes which are between 12 MB and 158 MB each. I have nearly 500 tabs open (because that's the limit) on my iPhone and iPad each, in Safari.
I usually carry 3 sets of tabs, typically around ~10 each:
Personal info sites, like reddit and its links...
Tech Sites, like HN and its links....
Video Sites, like Nexflix / Prime...
EDIT:
Also - what tab-mgmt extensions do you use? Like Tab Grouping etc...
Also - one of the things I attempted to do, but failed to do so consistently, was to swipe to a different desktop between, work, person, and learning/browsing... instead of tab groups I had "workspaces" but that is a hard habit to build, for me, it seems.
yea, tab-grouping is essential. (tabkit in the good old days, sideberry currently)
This is the way I do it as well - but I cant hold ~500++ 'context' threads in my head...
I typically hit a tab and wind up here: https://i.imgur.com/KWmVAD0.jpg
this is me
> 500 tabs open (because that's the limit) on my iPhone
that's my wife
I am trying to break myself of these habits, but they do have some benefits. For instance when I do a web search on a complex topic, I often scan the results, opening the most promising looking results as tabs. Then I look through the tabs comparing them. The trouble is I never remember to close them when the task is done.
Mainly just not having a workflow of going back to close them. So it's just previous work like a view of some logs, a merge request, a link to a file in a repo, a monitoring dashboard, an alert in a monitoring system, etc.
In Chrome, I do end up closing them eventually because there's no more space to work.
For personal:
it's more like a bookmark, but don't often review them rather than open a new tab to research whatever I'm currently curious about.
There's a whole spectrum of activity you can have on a tab, and to me I see really no difference between "unhibernating" a tab and just reloading it from scratch.
Either one is very slow in modern crap software.
Unless it happens under 150ms, it is slow.
... Actually the latter is incorrect, in truth I'd expect bookmarks to present me with the exact version I had in front of me back when I bookmarked it, including if the site is temporarily down, has vanished, or if I navigated a more recent version.
(TL:DR OOM errors and the kernel starts reaping processes)
Just seems so odd as I remember playing gta vice city on a pentium 3 with 128mb of ram and now I need 6GB+ to just browse the web
edit: That is, I think people sometimes attribute the lag they're experiencing to the number of tabs they have open, when only a handful of their tabs are to blame.
This gives me a way to instantly switch between contexts (with a small delay if a tab has to be reinstated from cache). This is how bookmarks should really work.
This us why Firefox is not the biggest memory hog on my system. Most of the RAM is consumed by language servers and Emacs.
The problem with this is that a lot of web pages don't handle this gracefully. You don't end up back where you left off!
It would be nice if all the details of the inactive web page were saved to storage, and then retrieved from storage when the tab is reactivated, without having to make any network calls at all.
Multi-process firefox seems to have absolutely obliterated the performance of firefox with large numbers of tabs until recently (it seems to be have improved).
I basically only upgrade workstations due to web browsers needs, and occasionally because a really big KiCAD project brings a system to a crawl. At this point even automated test suite runtimes are more improved by fixing things that stop test parallelization from working efficiently vs. bigger hardware.