ChromeOS and the Chrome browser recently gained a Memory Saver feature that helps free up memory on your computer. It works well, but it’s a bit of a blunt force instrument. Data gets wiped from unused browser tabs after a certain amount of time. So what’s a better, alternative method? An algorithm for the Chrome browser Memory Saver, of course!
That’s exactly what’s in the works, based on recent Chromium code commits. The code changes coincide with a new bug / feature report titled, “Add a less aggressive version of Memory saver“, with the following, high level description:
There’s desire to have a version of memory saver that doesn’t discard on a timer but instead considers memory usage signals for decision making. This bug tracks implementing this work.
A new experimental flag will enable the algorithmic Chrome browser Memory Saver feature to start. For now, it should appear as
Since work on this refactoring of the Chrome browser Memory Saver function only started this week, there’s little else to report. So I can’t tell you exactly how the algorithm will work. However, the starting point is there, and although it’s rather obvious, I’ve highlighted it below:
This policy changes the memory saver algorithm to be based on a set of experimental algorithms, the first iteration being a threshold of available memory.
Clearly, if you have plenty of available memory on your machine, there’s no need for the Memory Saver to discard tabs. Even if you haven’t used a tab for more than 10 or 15 minutes, discarding it won’t do much to speed up your online experience.
Google appears to be targeting several thresholds, or memory usage levels, to determine if and when a tab should be discarded.
For now, the algorithm appears to be using three different memory threshold levels along with some time-based metrics. These levels are shown above with profiles for Conservative, Balanced and Aggressive memory saving strategies.
Again, development of this Chrome browser Memory Saver update has only just begun. So it’s possible, likely even, that the approach or threshold levels could change based on optimization testing during the development phase. Either way, a smarter approach rather than a simple time-of-use solution will be very much appreciated.