Hacker News Reader

Comment by chx | Hacker News Reader

How much memory is saved here? http://www.httparchive.org/interesting.php?a=All&l=Dec%202%2... 52 _kilobytes_ ? Really?

The browser would have to save the source text for EVERY tab it opens, regardless of whether you view source or not. That seems more onerous than making a separate request for the source code every once in a while.

Yes, but if you have more than enough memory, then that's no problem.

So, the browser should load the HTML page into a part of memory that can be discarded by the OS if the OS needs more memory. Actually I think it is strange that no such memory API exists in Unix.

EDIT: Anyway, storing it in the browser's file cache would also do the trick, I suppose :)

Isn't that one of the issues nowadays, that people have the attitude "we have enough memory" and thus don't tend to care about optimizing for memory usage anymore.

Your suggested solution, about discarding when memory is needed, solves this problem. But it solves a problem that would be created by needlessly storing a lot more data than needed. So it's a solution to a problem that was not a problem to begin with.

But I know, if it's a few kb, it will not make a huge difference.

So hide it behind a feature flag?

> "we have enough memory"

Your phone is in disagreement.

My phone has a quite insane 3 GB of RAM.

My phone also has the insane 3GB of RAM, but last week Chrome killed Spotify and vice versa (music stopped playing) as soon as I switched apps. Sadly 3GB is not enough for Android and todays apps.

The most common $150 phone from last year only has 1GB, half of which is reserved for the OS.

We're talking about a default feature which is disabled 'for average users'. Average users only have a few tabs open in their browser. Not 100. Average users also don't have 3 GB RAM, nor do they use view source on a mobile phone, and neither do average users actually use the feature. So the default setting makes sense even though a user who is using the feature may end up using several MB due to a reload (not cool on a plan).

If you are saving 57 kB per tab open, that'd be ~5,7 MB with 100 tabs open. But if you have 100 tabs open on a mobile phone (!!), you have a bigger problem, and all those tabs are causing swapping already anyway. In that sense, enabling the feature by default makes sense. And don't forget that some people don't have flat rate internet.

100kb * 100 tabs is 10MB. I'll take my chances.

No this is really not the case of thinking we have enough memory. This is the realization that the static source code of a page is a percentage error compared to the memory overhead of a rendered page. The modern browser are memory hog I would rather they focus on that.

Its also a broken implementation function wise since I have asked for the source of the current page not of a reload.

Similar "tab discarding" feature already exists in Chrome, by the way:

https://developers.google.com/web/updates/2015/09/tab-discar...

> So, the browser should load the HTML page into a part of memory that can be discarded by the OS if the OS needs more memory. Actually I think it is strange that no such memory API exists in Unix.

It is more tricky then you would think to determine what "needed" memory means. Does the OS need disk cache? Or the content of memory mapped files?

It's not unlikely that you currently have some process active which has memory mapped a huge file. Does it need the content? Who knows.

You are talking about an OS-provided cache for the browser to store it's own cache in? There's little sense in that.

Moving memory management into the OS often makes sense, because the OS has the big cross-application picture, knows the system-wide memory pressure, and most importantly, already manages the memory of applications, by swapping between RAM and disk.

For the same reason, OS X and Android Linux both have systems for OS managed caches, and AFAIK Firefox already uses these: https://bugzilla.mozilla.org/show_bug.cgi?id=748598

The status on mainline Linux is a bit more nebulous (seems Android's ashmem has been upstreamed, but it's not directly usable on GNU/Linux systems?), and other efforts have stranded: https://lwn.net/Articles/602650/

For some more thoughts about memory management on OS level vs. application level, I can recommend this "random outburst" from the designer of the Varnish HTTP cache: https://www.varnish-cache.org/docs/trunk/phk/notes.html

But the amount of memory required for plain text source is very small compared to the memory allocated to render the page.

Am I in some parallel universe here ?

We are talking about hundreds of KBs of memory total which is nothing and if it's a worry for mobile devices we have the disk. It's not a feature that demands instant performance.

> It's not a feature that demands instant performance.

Hence it's acceptable to request the document from the server when opening 'View Source'.

No, because when you want to view the source you mean to view the source of this very document, not the source you'd get by asking to reload the page, it is often different.

If you want to see the page as it's currently being rendered, looking in the developer tools seems more relevant anyway.

If they wanted that, they'd have looked at the developer tools to begin with.

Many of you folks are completely missing the point. The world wide web took off in large part because it was incredibly easy to learn HTML, because with every webpage if one wanted to know how it worked one could just look at the source code.

How the page is currently being rendered, what state the DOM might be in... These things do not matter to someone trying to view the source HTML for a page. They're looking to learn about the HTML. They're not goimg to get that by viewing pre-digested DOM information.

Or a website I was trying to fix: the source in view source, and thr stuff on dev tools, never matched each other, even with JS disabled. in the end after days I gave up and the page is in production, crazy bugs and all, because I can't figure why on both chrome and Firefox the webpage end with lots of random "strong" and "span" tags that don't exist anywhere in the original source. The tags aren't even closed properly, some are never closed, some are closed multiple times.

Thats just it...

There are edge cases where a bug is intermittent... and is masked by something on the client side, especially possible with browser plugins. In fact, plugins were the cause of 2 of these for me... Where some issue on page load was causing a bug, but then JS was changing the source away from what cased the bug, but a refresh wasn't guaranteed to have the same information (this was a fast changing log-viewer, for one of them) ...

So you end up not being able to capture the init state of the page... but the bug wouldnt show up without JS enabled because the error is in the JS...

Not common case... but it seems like fetching from the server is MORE work for no reason when the data is already there...

No it's not, and it's particularly inappropriate for any document being viewed as a result of a POST request.

But who does this feature help exactly? A _tiny_ number of users. Chrome is currently using over 3GB on my machine. Anything they can do to trim that without affecting performance is worth it to me.

3GB is how much memory the _rendered/executed_ source code takes. The source code is nothing. Store it LZ4 compressed in memory and it's less than a rounding error.

Yes, I know that, but all of these little inefficiencies add up, and for what? A tiny portion of users who need the developer tools? Not worth it.

This kind of thinking is exactly what leads to our software being as slow or slower than that of two decades ago while running on machines hundreds or thousands of times more powerful.

What everyone is missing here is that one in ten thousand users needs this, so why optimize for the vast minority?

Reply on news.ycombinator.com