6 ms·
If I open this HN discussion page in the browser, it currently uses 44MB of private memory. We can definitely shave a couple of megabytes off of it with some e
by akling 5y ago
If I open this HN discussion page in the browser, it currently uses 44MB of private memory.
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.
- kragen 5y agoNice! Thanks! That's a real improvement over the existing browsers! Yeah, clearly you can't run Slack or Fecebutt in 4MiB, but there's a lot you could do. 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.
- rasz 5y agohttps://get.opera.com/pub/opera/win/1218/en/ https://get.opera.com/pub/opera/win/1218/en/ Opera_1218_en_Setup_x64.exe Default portable install. 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 Opera needs ~5MB to load and properly render this page, and 28MB for the rest of the browser. Btw it also gets 100/100 on http://wpt.live/acid/acid3/test.html http://wpt.live/acid/acid3/test.html :-)
- bla3 5y agoI doubt existing browsers need much more memory for HN. It's a tiny page.
- fragmede 5y agoFor reference, this page+assets are 187kB. I'd guess the bulk of that 44MB comes from having css and javascript on this page, but a breakdown of what it's using 44 MiB on would be interesting!
- kragen 5y agoObviously I don't know anything about the Serenity browser, but in the Gecko/WebKit/Blink cases it's mostly startup overhead. A page with a single word on it ends up being more than 44MB. The DOM is a braindead abortion that should never have been standardized. There's no plausible way to implement it with reasonable efficiency.
- pigeonhole123 5y agoThat last part sounds interesting. Can you elaborate?
- kragen 5y agoDOM nodes are mutable and have parent pointers, so there's no way to share structure between duplicated parts of the element tree; JS might mutate them to no longer be duplicates. NodeLists like the .childNodes property (but not the results of, say, .querySelectorAll) are required to be "live", magically updating when you change the document; this code produces 1 even though there's no explicit mutation of c: let d = document, b = d.body, c = b.childNodes, n = c.length; b.appendChild(d.createElement('div')); console.log(c.length - n); So to a significant extent we're stuck for eternity with the design tradeoffs and even bugs of Internet Explorer 3, because bugs like this one are exposed through this interface and standardized by the W3C. 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'> might become { 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" ... } } } } assuming the tag names and attribute names and values are indices into a "symbol table" in a UTF-8-style variable-length encoding, an encoding which is also used for byte string lengths. This encoding reduces the original 97 bytes of this fragment (plus its end tags) to about 57 bytes. 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.)
- c-smile 5y agoThis really depends on design goals of course. 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.
- kragen 5y agoInteresting! I didn't know about Sciter, but to me it sounds like Sciter kind of is a browser, heavyweight DOM and all: https://sciter.com/ https://sciter.com/ Proprietary though, same as Presto, so I guess it's kind of a dead end.