Right now (2023-02-25T09:48+00) I have 10 tabs open in Firefox (Windows 10, x64, private window).
Their total RAM usage is around 1088 Mb.
Only 2 of them play videos (youtube). Others don't do any meaningful work.
How can a browser be designed and implemented such that it takes 1/100 as much RAM as current popular browsers take?
If that is PHYSICALLY IMPOSSIBLE, what about 1/80 or 1/50 or even 1/10?
Surely browsers can be better.
@armagan1 you'd have to remove all the security aspects (sandboxing, isolates, etc), load less assets (or keep them swapped out until you need them), and disable Js.

@wanninger How much RAM does security really need? It doesn't seem like it uses much in OS kernels.
How much would it use if it is taken to its practical minimum limit while preserving all its aspects?
Assets and even browser, JS code should be lazy loaded. I think that would help immensely.
JS code and data should be securely shared when its possible.
Ideas from Functional Data Structures can enable an efficient way for sharing (e.g. structural sharing).
The interpreter code and immutable data can be shared.
A new tab shouldn't use any RAM for JS if it doesn't have mutable JS data or code.

Even 3rd party code can be shared securely. Copy-on-write semantics can be used if it's modified by a tab.

If we share every possible code and data in a secure and efficient manner with every system/subsystem, and don't load any code or data until it's necessary, I think the RAM usage will drastically reduce.

How can I precisely and easily inspect how much RAM each part of browser's subsystems use?

@armagan1 At least in v8, almost all of the relevant data structures you'd want to optimize are already optimized for space if they were a problem. The additional overhead of sharing (ownership tracking, sync, etc) would probably outweigh the benefit from sharing.

Personally, I can't imagine maintaining such code in a way that maintains performance -- especially at the scale of a browser engine (w/o rewriting in a language which supports those functional data structures performantly).

I think Google released a report at some point that the v8 JIT (turbofan) was actually one of the larger memory footprints in the browser (which makes sense, x86 code has pretty low density compared to the ignition bytecode format. see: https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-november-edition).

Another question is, are you looking at resident set size or virtual memory usage? I find that browsers often over-provision their virtual address spaces without actually using that memory.

A modern web browser is, to some extent, more complicated than an operating system kernel -- excluding drivers. I think the core answer here is "sacrifice most of your performance and compatibility and you will get back a little bit of memory".

V8: Behind the Scenes (November Edition feat. Ignition+TurboFan and ES2015) · Benedikt Meurer

Personal website of Benedikt Meurer, JavaScript Engine Hacker and Programming Language Enthusiast.

@wanninger

What if we build a browser ecosystem from scratch with a fresh perspective?

I want to be able to have thousands of browser tabs running concurrently.
The modern hardware can handle this load if we build the browser with this goal.

How does Erlang handle thousands of "processes" easily? I know they are not real processes but the ideas from the Actor Model and Erlang can revolutionize how we create browsers.
.
Surely there can be a common system which handles thousands of "processes" as browser tabs.
Sharing common immutable data/code would help immensely if there was such a system.

Basically, a browser built on Actor Model, with high density bytecode and which shares code/data as much as possible.
Performant functional data structures and structural sharing systems will be written once as a common subsystem. That is not a concern.

I want these personally as a browser user (and someone with a computer engineering degree) who wants to experience the full power of modern hardware. Currently, most modern software is written sloppily.

If we care enough when creating software, the results might surprise us.