Consider tweaking browser.sessionstore.interval

[gunir]

By default Firefox is writting session file every 15s (15000ms), the more tab, history your Firefox is using, the more expensive CPU, battery and disk usage.

For example 10 tabs your session file is about KBs, but once you enter hundreds, thousands tabs territory, the file grows bigger to even MBs, 100+MBs.

Increasing this value to higher number, I mean 30min (1800000) or 1 hour (3600000) will reduce this by a lot because writting session every 15s is OVERKILL, and this is only for crashing, so unless your Firefox crashes, there's nothing to worry about because quitting or restarting Firefox immidiately write session file.

This tweak will likely benefit thoses who complain about Firefox battery usage.

[yokoffing]

The very reason the preference exists is in case Firefox crashes. Similar to insurance, it's not a big deal until a "crash" happens to you 🙃

You can comb back through old user.js releases and see I bounced around with this pref for awhile. I leaned heavily on the performance aspect. But it only took the electricity going out one time for me to learn my lesson.

We must preserve users' ability to recover their work after a crash. If we set the value for too long, then the tabs aren't captured or are outdated. Too short and you have the potential performance drawbacks of frequent session saves.

But the priority is that you can recall your work (for folks not using sanitize on shutdown). That's how we landed on the current value of 1 minute, which is a 4x improvement (performance) and short enough in most cases not to miss new tabs (experience).

You're still able to set it to any value you want in your overrides at the bottom of the user.js file.

We may could move it to 5 minutes, but even that can be annoying in some scenarios (as if the browser crashing isn't annoying enough).

---

Per the metabug 5 years ago:

A significant amount of work happened since this bug was first filed that has reduced the severity of the problem.

Yet,

There's still more that can be done

There is also new activity on the bug report showing an increase in the file size:

This came up recently, so I had a check: my current session restore file is 2.4M (double that of the initial report), and last year the 75th Percentile of sizes was 950k, so 25% of our users have a file >1M. So despite adding compression, this got worse compared to https://bugzilla.mozilla.org/show_bug.cgi?id=1304389#c22.

So it is creeping up from the average of 8 years ago, even though data is only saved when state changes, but probably not 100+ MBs.

Hopefully there will be further tweaks soon.

[gunir]

But the priority is that you can recall your work (for folks not using sanitize on shutdown). That's how we landed on the current value of 1 minute, which is a 4x improvement (performance) and short enough in most cases not to miss new tabs (experience).

That's great! For me I personally use 1 hour, my session file is currently 78MB with 10.000 opening tabs and it's pretty intense to have this value low.

So it is creeping up from the average of 8 years ago, even though data is only saved when state changes, but probably not 100+ MBs.

I think the Mozilla engineer didn't understand that even if it writes when state is changed, state always change, for example opening or closing tab is something you do like everytime, open a Reddit thread, open links from it, and so on.

And it still reads every 15s which is bad enough, because there's no way they know if state is changed without reading last session and comparing with it, there's no way in programming for me.

[yokoffing]

10.000 opening tabs

While I aim to accommodate a wide range of users, managing 10,000 open tabs is a niche scenario that falls outside the typical use patterns I consider. But again, luckily, you can make any changes you want in the overrides section of the user.js.

even if it writes when state is changed, state always change, for example opening or closing tab is something you do like everytime, open a Reddit thread, open links from it, and so on.

You're right that state changes occur frequently during normal browsing. That point seems obvious, but maybe there's some greater context we are missing as end users.

there's no way they know if state is changed without reading last session and comparing with it

The concern here isn't about detecting changes, but rather the potential performance impact of constantly rewriting session data for tabs. But there could be a separate bug where the comparison detection is a concern. I haven't looked.