My biggest complaint about modern browsers is that I can't load a web page in less than 64 MiB, which is more than my entire computer had when I was running Netscape 3. The browsers are better now, but not in ways that necessarily use more memory.
At this stage, we're primarily focusing on correctness and compatibility, and performance is mostly a luxury. It's an area I look forward to eventually dealing with though, as it used to be my full-time job at Apple years ago and I have many fun ideas. :^)
I think of memory usage as being more about correctness than performance, though I know that isn't how most people see it. Trying to run a 512MiB process on a 64MiB computer, or a 512GiB process on a 64GiB computer, is just never going to run at a usable speed. Broken software is the limit as latency approaches infinity.
Moreover, I've never seen someone take software that needed 1 GiB to run and modify it incrementally into software that could run in 1 MiB, though I have seen the opposite.
We can definitely shave a couple of megabytes off of it with some effort, but supporting the contemporary web on a 4MB budget seems infeasible.
Even Lynx takes 14MB of RSS (not all private!) and 25MB of VSZ to load this discussion page, and Links is 9MB/13MB. (Neither of them produces a usable layout, but that's not because they're using a lot of memory.) The page source is 179K, links's "formatted output" of the page is 59 kB, and Firefox tells me it has 2908 HTML elements in it, so it's probably possible to render it in under a meg. I doubt anyone ever will.
27.8MB windowed, one empty tab open
24MB minimized, one empty tab open
35MB windowed, one tab open with this thread loaded and scrolled once up and down
31MB minimized, one tab open with this thread loaded and scrolled once up and down
33MB windowed, one tab open with this thread loaded after restart
29MB minimized, one tab open with this thread loaded after restart
It used to be my favorite browser on Windows NT 4, last millennium.
The DOM is a braindead abortion that should never have been standardized. There's no plausible way to implement it with reasonable efficiency.
let d = document, b = d.body, c = b.childNodes, n = c.length; b.appendChild(d.createElement('div')); console.log(c.length - n);
If you weren't constrained by W3C DOM compatibility and wanted to trade off lower memory usage for slower small mutations, one extreme strategy would be to maintain chunks of the page tree as Polish-notation bytecode instead of materialized nodes full of pointers; then this discussion-thread page, with its 60 K of text and 3000 HTML elements (expanded to 4758 since my earlier comment, but let's disregard that), might require 80K of RAM instead of 512K or more. So for example
<tr class='athing comtr' id='30861517'><td><table border='0'> <tr> <td class='ind'indent='3'>
{ tr # 2 bytes
attr class "athing comtr" # 3 bytes
attr id "30861517" # 4 bytes, plus 16 or so for the string table entry
{ td # 2 bytes
} # 1 byte
{ table
attr border "0"
text " " # 4 bytes, text is inline with prefixed length
{ tr
text " " # 6 bytes
{ td
attr class "ind"
attr indent "3"
...
}
}
}
}
You wouldn't want to store the entire page as a single long string of such bytecode, because that would make tree traversals unreasonably slow. You'd limit the bytecode blocks to 32–256 operations and then build a more conventional node tree or B-tree to knit those leaves together into a whole document. Mutations to the page inside such a leaf block would require rebuilding the block.
In 02022 slower small DOM mutations seems like a very reasonable idea given the prevalence of things like React which tend to rebuild large parts of the page from scratch anyway.
Of course even more extreme points on the time/space tradeoff curve do exist; you could reparse the HTML source from an LZMA-compressed representation on every redraw (compression ratio 8.3 on the current 304kB version of this page, so the 179K incarnation we've been using as an example would be about 22K, and a little HTML minification might squeeze that down further). But my intuition is that even with current CPUs you wouldn't get reasonable performance that way.
Why "512K or more"? The DOM more or less requires pointers to parent, nextSibling, and firstChild, which we can suppose are 64 bits, plus a 64-bit field for node type and padding, which gives us 32 bytes per node; there are about 0.85 text nodes per element, so we have about 5400 nodes for 3000 HTML elements, giving 172.8 kB, and adding in the size of the text gets us past 256KiB. And then we need some space for attributes, cached layout, cached styles, etc. So 512K is easy and the reality is more like 1–4 MiB. For a page that Links renders into 60K of UTF-8 text!
For more markup-heavy pages, which is almost all of them, the ratio is larger.
An intermediate tradeoff would be something like Fredrik Lundh's ElementTree interface for Python, but with iterators over the tree represented as variable-size paths down from the root, permitting hash consing to automatically share structure between all the instances of <td class='ind' indent='4'><img src="s.gif" height="1" width="160"></td>, "reply", " | ", "[–]", and <a href="user?id=akling" class="hnuser">akling</a>. Moreover the ElementTree design doesn't require type-tag fields (though CPython of course does spend memory on them).
In ElementTree each element has string attributes .tag, .text (the leading CDATA text inside the element, possibly None in the Python implementation, which I see as a design error), and .tail (any CDATA text that follows the element, also possibly None in the Python implementation), a list of zero or more child elements, and a possibly-empty string-to-string map (dict) of attributes. There are no parent pointers, though the mutability of ElementTree itself means you still can't share child subtrees that happen to be equal. Child elements are always elements; text and tail are always strings (except where null).
Consider a FORTRAN-style linked-list representation of an ElementTree. For a page tree of up to 65535 elements, 65535 text nodes, and 65535 name-value pairs, you could represent these as arrays of 16-bit integers, assigning each element a 16-bit element ID used to index parallel arrays of 16-bit ints named TAG, TEXT, TAIL, KID, NEXT, and ATTR. KID and NEXT contain element IDs which are -1 to indicate no children or no following siblings, respectively. ATTR may contain -1 (no attributes) or index three parallel arrays named NAME, VALUE, and MORE, the third of which contains -1 or another index into these three tables. TAG, TEXT, TAIL, NAME, and VALUE all index a string table, which is an array of 32-bit ints named START. START indexes an array of bytes named CHARS, and there's an allocation pointer FREE which points to the lowest unused index in START. The bytes of string N start at CHARS[START[N]] and continue to CHARS[START[N+1]]; the first unused byte in CHARS is at CHARS[START[FREE]]. Optionally you can build a hash table over the entries in START to allow the reuse of duplicate strings, since you can't efficiently insert or delete characters within an existing string anyway.
This works out to 12 bytes per element, 6 bytes per attribute, and 4 bytes per string, and it allows mutation just as efficiently as the Python version (i.e., you have to make a copy of any string you want to modify, but you can insert and delete elements in constant time, or graft them onto a different part of the element tree). And it's simpler, not more complex, to iterate over or evaluate CSS-style selector queries on, than the W3C DOM.
With this representation, if you had 3000 elements, 3000 attributes, and 2500 strings totaling 60 kB of text, you'd need 124 kB of memory, plus allocation overhead. And if you're in a reasonably dynamic language you can replace these arrays of 16-bit integers with arrays of 32-bit integers whenever one of these collections goes over 65536 elements. (In Numpy this is quite transparent once it is done.)
>>> from xml.etree import ElementTree
>>> def text(e):
... return (e.text or '') + ''.join(
text(kid) for kid in e.getchildren()) + (e.tail or '')
...
>>> text(ElementTree.fromstring('<p>My <b>Malamute</b> is <i>really</i> hairy.</p>'))
'My Malamute is really hairy.'
>>> def find(e, clase):
... if e.get('class') == clase: yield e
... for kid in e.getchildren():
... for nieto in find(kid, clase): yield nieto
...
>>> list(find(ElementTree.fromstring('<p>My <b class="dog">Malamute</b> is <i>really</i> hairy.</p>'), 'dog'))
[<Element 'b' at 0x7f14717c7a10>]
On the other hand, without the dopey None case I objected to above, you wouldn't need the "or ''".
function getText(node, returnArray){
const a = Array.prototype.map.call(node.childNodes, e=>e.nodeType==3?e.data:getText(e, true))
return returnArray?a:a.flat(Infinity).join("")
}
let getText=(n,f=(n,a)=>[].map.call(n.childNodes,e=>e.nodeType==3?e.data:f(e,1)))=>f(n,f).flat(1e333).join("")
Still, I think that
let getText = n => n.text + n.getchildren().map(getText).join('') + n.tail
let getText=(n,f=(n,a)=>[].map.call(n.childNodes,e=>e.nodeType==3?e.data:f(e,1)))=>f(n,f).flat(1e333).join("")
let getText = n =>[].map.call(n.childNodes,e => e.nodeType == 3 ? e.data : getText(e)).join("")Usually browsers are tend to sacrifice memory consumption (e.g. caching) for rendering speed.
In Sciter, for example, this page on HN occupies less than megabyte in RAM. Sciter has quite different design goals than browsers.
Proprietary though, same as Presto, so I guess it's kind of a dead end.
(You need additional display-list items for things like the #ff6600 bar at the top and the #f6f6ef background, but those occupy insignificant space even compared to the 2144 characters. The Yahoo/Y-combinator logo and the arrows also add a little bit.)
Of course #notallpages are mostly text, and many of them will require intermediate storage for large photos, <canvas>es, or screenshots of faked Tweets.
If you're on a smaller computer you might render one scan line at a time from a display list consisting of strings rather than individual characters. Those 2144 characters are in 29 lines, so the display list might be under 3K, and a 400-pixel 1-bit-per-pixel scan line is 50 bytes. If you're generating PAL this way you have 64 μs to render each line, which is about 1000–6000 instructions on current microcontrollers, and you can maybe manage 450 color pixels, another 2K or so of raw pixel storage.
... but... the GPU shader will need a surface to render into, no ? do you know of any OS where asking for a 1000x1000 surface does not allocate space for that in normal, non-GPU RAM ? I believe that this uses RAM on any mainstream desktop OS
I'm not sure it's fair to charge that framebuffer to the browser, though. The windowing system needs to use the same 31MB before you start the browser up, after all.
I don't know the answer to your question about mainstream desktop OSes and space allocation for shaders for windows that aren't being displayed. Maybe someone who knows more than you or me can chime in.
every process needs its own surface for compositing though. If you open 200 4k windows you'll get 200*31MB, they aren't going to share the memory with the desktop one
The pages you look at also have gotten ‘better’ in ways that necessarily use more memory. I don’t think you regularly loaded megabytes of JavaScript.
Finally, your browser usage likely has gotten ‘better’ in ways that necessarily use more memory. I guess you have more tabs open than you ever had in that 64 MiB.
As for JS, on most pages the only benefit of those megabytes of JavaScript is that I need to use uBlock Origin and/or Reader Mode to read what I'm actually interested in, the page jumps around at random while I'm trying to read it, Twitter tries to extort me into logging in, DoubleClick and reCaptcha can fingerprint my GPU, etc. Also, a megabyte of minified JS might reasonably compile down into a megabyte of bytecode or 4 MiB of native code, not 64 MiB or 128 MiB. JS's execution model is kind of inherently memory-hungry, though.
64 MiB is for one tab.
Basically that's the same memory usage as Blink, WebKit, or Gecko.