6 ms·

We haven't really begun to optimize for memory usage yet, so it swings wildly depending on the content you're viewing. At this stage, we're primarily focusing

• kragen 5y ago
  What's a rough minimum for a page with some text on it? Are we talking about 64MiB like Chromium, WebKit, or Gecko, or more like 16KiB, 256KiB, 4MiB, or 1 GiB? 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.
  • 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 ago
      Nice! 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 ago
        https://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 :-)
        • kragen 5y ago
          Impressive! I thought Opera was using WebKit now so it was as bloated as anything else? It used to be my favorite browser on Windows NT 4, last millennium.
          • rasz 5y ago
            This is the last Presto build ever released from 2016.
            • kragen 5y ago
              Oh, I see. Thank you. RIP.
      • bla3 5y ago
        I doubt existing browsers need much more memory for HN. It's a tiny page.
        • kragen 5y ago
          Try it. You'll be amazed.
          • 5y ago
    • fragmede 5y ago
      For 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 ago
        Obviously 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 ago
          That last part sounds interesting. Can you elaborate?
          • kragen 5y ago
            DOM 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 ago
      This 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 ago
        Interesting! 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.
  • jcelerier 5y ago
    The lowest bound would be the size of the texture the page is rendered into, no ? If you're on a 4k screen an uncompressed rgba pixmap is already 31MB... And that's really just the raw pixel storage which needs to be associated with your process
    • kragen 5y ago
      You don't have to render the whole page to a pixmap at once; it's very reasonable for a display-list representation of the page using a font atlas to be a tiny fraction of that size, maybe 8 bytes per character, and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand. 2144 characters of text on my 1920×1080 display extrapolates to 17152 characters on a 4K display, which would be 140K of display-list data. 0.14 MB is a lot less than 31MB. (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.
      • jcelerier 5y ago
        > and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand. ... 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
        • kragen 5y ago
          The GPU shader could in theory be rendering into a tile that gets squirted out to the screen by the RAMDACs and then reused, but I think you're right that in practice the GPU has at least one full-screen framebuffer, usually two or, dismayingly, three. Often the monitor has an additional two or three! 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.