News for hackers. Stuff that matters.
Re:Flow browser passes the Acid tests by htk on Saturday June 13, 2020 @09:47AM (#23509319)
Yesterday I stumbled upon a post here about a guy trying to use a Pi as his main machine for a couple of days, and one of his conclusions was that he needed 8GB of ram to run Chromium acceptably, and I thought, hardware evolved to these amazingly small and powerful machines but software is bloating faster. All this is to say that software such as Flow might be the way to go back to more performant ways of doing “essential” computing.
Re:Flow browser passes the Acid tests by nostrademons on Saturday June 13, 2020 @12:37PM (#23510650)
There was a meme when I was at Google (~2012) that went:

"What would you do if you had 16GB of RAM?"

"I'll tell you what I'd do with that. 2 Chrome tabs at the same time."

(Superimposed over the scene from Office Space.)

(On a more charitable note, I worked with the Chrome performance team on a few occasions. The reason for Chrome's massive memory requirements is that they make memory vs. CPU/performance/security tradeoffs on a regular basis, and usually make them against memory. For example, the reason you can have smooth animations in Chrome is because there are multiple in-memory representations of the layout and changing a CSS property relies on cached parsing/cascading/layout decisions and only needs a repaint on the GPU, using blocks of the page that have been pre-rendered into a texture. For another example, the multi-process architecture that gives each webpage isolation from another is a lot more RAM intensive than a shared-state architecture that could share common components, like say the object code from compiling shared JS libraries.)

Re:Flow browser passes the Acid tests by xenomachina on Saturday June 13, 2020 @01:59PM (#23511268)
> The reason for Chrome's massive memory requirements is that they make memory vs. CPU/performance/security tradeoffs on a regular basis

Do they actually test both approaches, or is it more a matter of "we can code it way A or way B, and way A uses more memory, but we think it'll be faster"?

Many years ago I worked at Watcom, back when they made "the" C++ compiler for DOS games. (Doom, Descent, Duke Nukem 3D, and Tomb Raider all used it.)

The compiler had various optimization settings, and some optimized for size, while other optimized for speed. The compiler was used to compile itself. They normally compiled with the "optimize for size" settings enabled, but one time they decided to try optimizing it for speed to see how fast it could be.

It turned out that optimizing it "for speed" made it considerably slower because of the cache.

Re:Flow browser passes the Acid tests by esprehn on Saturday June 13, 2020 @03:03PM (#23511790)
The chrome team does exactly what you describe. They both compile for size on some platforms (because in practice it's faster for several reasons) as well as spend a lot of time researching speed vs memory trade offs and making those deliberately. In recent times the memory trade offs were also sometimes related to reducing power consumption.
Re:Flow browser passes the Acid tests by phamilton on Saturday June 13, 2020 @09:22PM (#23514343)
There was a lot of debate back in the Gentoo days about whether to compile with -O3, -O2, or -Os

-Os meant faster launch times, which for desktop Linux made sense, but in classic Gentoo fashion a big group used -O3 and then did a bunch of hacks to make sure binaries would be loaded at startup and never be evicted from memory (even if the application itself wasn't running).

Gentoo was delightfully silly about this stuff, and mostly self aware that it was excessive.

Re:Flow browser passes the Acid tests by IgorPartola on Sunday June 14, 2020 @09:17AM (#23517445)
Oh god I remember this. Compiling the compiler to compile it again to compile the kernel to install everything. Every few weeks. While trying to find something that used less memory than openbox.
Re:Flow browser passes the Acid tests by MereInterest on Saturday June 13, 2020 @10:55PM (#23514725)
Depending on the conditions, you can get faster speed with -Os even if the binary is never evicted from memory. If you are optimizing for size, then you may be able to fit more of the program into the CPU cache, which can be accessed much faster than the main memory.
Re:Flow browser passes the Acid tests by TylerE on Sunday June 14, 2020 @12:37AM (#23515156)
Weren't there tests back then that showed -Os was actually faster on a lot of modern CPUs? Something like more of the binary staying in CPU cache?
Re:Flow browser passes the Acid tests by gsnedders on Saturday June 13, 2020 @02:40PM (#23511601)
> Do they actually test both approaches, or is it more a matter of "we can code it way A or way B, and way A uses more memory, but we think it'll be faster"?

A lot of memory consumption is various caches (at various layers); those caches weren't added for no reason, they were added because they provided a demonstrable a perf gain.

Re:Flow browser passes the Acid tests by fouric on Saturday June 13, 2020 @02:02PM (#23511287)
> The reason for Chrome's massive memory requirements is that they make memory vs. CPU/performance/security tradeoffs on a regular basis, and usually make them against memory.

This is generally a good trade. Memory is not very useful (modulo filesystem caches) when you're not using it, and has a very low cost when you are (extremely tiny power consumption). CPU cycles cost power (leading to heat dissipation and battery life loss) when you use any amount, and latency when you use too much. Latency directly affects user experience and efficiency, which is a much higher cost than "my RAM is at 75% usage".

Additionally, Chrome's tradeoff is such that it works out better on cheaper devices. Memory is far cheaper than more powerful processors - which also reduce battery life, which is even more expensive. On more expensive devices, you have all the memory you need for Chrome anyway, so you're just getting better latency.

Finally, there are very few cases where you should have a large number of Chrome tabs open anyway. Multi-tasking is impossible (the human brain simply doesn't support it) and rapid context-switches are inefficient. As much fun as it might be to have 5 tabs open on each of 10 different topics, you're simply decreasing your productivity and capacity for focus. Even when doing multi-disciplinary research, there are a ton of ways to get around the problem of running out of memory due to Chrome tabs: printing pages to PDF, turning off JavaScript, downloading research papers and reading them in a native PDF viewer, extracting content from webpages and inserting into local documents, and the classic using darn bookmarks instead of tabs like they were intended to be used.

(of course, in an ideal world, all web browsers would use absolutely no memory or processing power whatsoever - I'm just defending this particular engineering tradeoff)

Re:Flow browser passes the Acid tests by MereInterest on Saturday June 13, 2020 @11:01PM (#23514749)
> Finally, there are very few cases where you should have a large number of Chrome tabs open anyway. Multi-tasking is impossible (the human brain simply doesn't support it) and rapid context-switches are inefficient.

I agree that the human brain doesn't task switch effectively, but that is exactly why I want to have many tabs open. In the case of reading Hacker News, I will go through the main page once, opening each article and comment page in a new tab, then will use that as a to-read list. If I am researching how to do a task, I will open have several pages open for documentation, stack overflow posts, bug reports, etc. These are open not for the sake of multitasking, but in order to reduce the amount of working memory I need. For example, if a post mentions that a particular workaround may be required, then I want to keep that tab open until I have verified that that workaround is not needed in my case.

Re:Flow browser passes the Acid tests by rossjudson on Sunday June 14, 2020 @12:53PM (#23519224)
Sounds like you want bookmarks with state/tagging.
Re:Flow browser passes the Acid tests by 0-O-0 on Sunday June 14, 2020 @02:41PM (#23520108)
Are there any solutions with good UX for this workflow?
Re:Flow browser passes the Acid tests by fouric on Sunday June 14, 2020 @02:33PM (#23520025)
I guess I'm making two claims here: (1) you should only open tabs for the task you're currently working on and (2) that very few tasks require large numbers of tabs. Fine, maybe it's more then a dozen, but the graph of "number of tabs used by a task" versus "frequency of that number occurring" is an inverse exponential (e.g. most tasks require 1 tab, fewer require 2, even fewer require 3, etc.), and I've never noticed myself actually needing more than...probably 20 tabs to complete a single task before.

> In the case of reading Hacker News...

This isn't a "task" - you're reading a bunch of completely separate articles, one at a time. You're consuming, not producing/processing/working on a task/problem - and each element of consumption is separate than all of the others.

> If I am researching how to do a task...

I understand and agree with this definition and workflow! This is how tabs were designed to be used. However, I haven't ever seen a common task (for programmers - who have even more demanding requirements than the general populace) that requires a "large" number of tabs. I guess that's kind of vague and I can always change the number, but really, think about it - how often does a task require more than a dozen tabs? More than two dozen tabs?

Just for fun, I opened every frontpage article (as of the time I accessed it - whoops, should have used Wayback HN or something) in Chrome. All 30 articles took 3.9 GB RAM, and adding all 30 pages of comments consumed another 300 MB, so 4.2 GB. total.

Re:Flow browser passes the Acid tests by afiori on Sunday June 14, 2020 @04:52PM (#23521264)
I disagree with the first claim:

> (1) you should only open tabs for the task you're currently working on

In good part because there are no other simple "read later" alternatives in a browser.

Something that would be an option would be a special single use kind of bookmark that gets deleted once you reopen it.

I am on the extreme side of keeping too many tabs open, part of the reason is that they offer a very simple and unique functionality in the browser (it was my reason between other to switch to Firefox, it could easily handles a few hundred tabs (with some restarts from about:profiles))

Re:Flow browser passes the Acid tests by andrekandre on Saturday June 13, 2020 @07:25PM (#23513735)
> Finally, there are very few cases where you should have a large number of Chrome tabs open anyway.

from what i observe in others, it seems that tabs get created when a new task needs to be done in the same site (that is already open) but dont want to loose context of the previous ones...

from my own personal experience, i like to reuse them as much as i can, but it gets harder as more and more get added, its easier to start from scratch and get a new tab open and go where i want to go...

i think browsers could be doing much more than just tabs and bookmarks to help people organize, because right now it seems like the equivalent of a desk with lots of papers strewn around where someone grabs yet another blank peice to start writing on...

Re:Flow browser passes the Acid tests by kortex on Saturday June 13, 2020 @09:31PM (#23514401)
> i think browsers could be doing much more than just tabs and bookmarks to help people organize, because right now it seems like the equivalent of a desk with lots of papers strewn around where someone grabs yet another blank peice to start writing on...

Absolutely. Zettelkasten is the hotness right now. I'd love to see something like a cross between Zettelkasten and Zotero.

Personally I want something in between bookmarks (which I actually infrequently revisit) and history, which is everything and too much noise, and also not permanent in case of history wipe. Strangely I bookmark a lot but don't revisit often, but when I _don't_ bookmark something and need to find some memory thread, it's awful.

I've been scheming about something which I could hit a hotkey, grab the text and metadata, index it, and save the index, set of words/ngrams, or maybe just zipped html content, it's light enough. Then some personal search interface.

https://news.ycombinator.com/item?id=22160572

Re:Flow browser passes the Acid tests by fouric on Saturday June 13, 2020 @07:55PM (#23513903)
> from what i observe in others, it seems that tabs get created when a new task needs to be done in the same site (that is already open) but dont want to loose context of the previous ones...

Could you give a few examples of this? I still can't think of anything particularly common that would reasonably justify more than a dozen tabs at once...

> i think browsers could be doing much more than just tabs and bookmarks to help people organize, because right now it seems like the equivalent of a desk with lots of papers strewn around where someone grabs yet another blank peice to start writing on...

Yes, I completely agree. I'm working on a piece of software that goes several levels beyond what browsers currently offer for information organization, and (per the topic) it optimizes for CPU consumption at the expense of memory, for the reasons I gave in my comment. However, for the browsers that we have now, bookmarks are much better for organization than tabs. You can tag them, name them, and put them into folders - none of which you can do with tabs.

Re:Flow browser passes the Acid tests by icebraining on Sunday June 14, 2020 @05:30AM (#23516261)
I find bookmarks literally useless nowadays.

For example, currently I'm researching bicycles for my mother. I'm on an online shop, and I just open potential candidates on new tabs, which means they start loading in the background while I keep browsing. And using Tree-Style Tabs, this makes them all "children" of the listing tab, which would be lost information if I bookmarked them instead. When I switch to another task, I can just collapse this tree, and when I get back, the listing will be exactly where I left it, which is particularly useful if the site uses JS search without updating the URL. Bookmarks lose all the memory except for the URL and page title.

Bookmarks could be useful for a long-term reference storage (months/years instead of days/weeks), but then chances are a bunch of those links will have rotted, so I need to use something that mirrors the content instead (I used Pinboard previously, now I just use the SingleFile addon to store it as a file).

Re:Flow browser passes the Acid tests by fouric on Sunday June 14, 2020 @02:50PM (#23520210)
> And using Tree-Style Tabs, this makes them all "children" of the listing tab, which would be lost information if I bookmarked them instead.

Bookmarks can be categorized with folders and tags - which, together, are much more flexible than tab groups. A tab can only exist in one group/tree at a time, but a bookmark can have infinitely many tags and exist in a tree-like structure (which is what you described) using bookmarks and be relabeled so it's easier for you to find using full-text search.

> Bookmarks lose all the memory except for the URL and page title.

Yes, because bookmarks are meant to be long-term storage, tabs are meant to be working memory, and transient web page state like whether a radio button is checked or not is not intended to be long-term. Web page state is supposed to either be stored server-side or client-side using cookies or HTML5 local storage - which persist after the tab is closed.

> if the site uses JS search without updating the URL

Then you can just keep that search tab open if you absolutely have to interrupt yourself and go to another task. Bookmarks will do just fine for all the stuff you found. It's extremely unlikely that you're going to have more than a few of these tasks that all absolutely require page state that isn't present in the URL or through local storage and you're accumulating them faster than you can complete them.

Re:Flow browser passes the Acid tests by icebraining on Sunday June 14, 2020 @03:15PM (#23520473)
To be clear, I'm not arguing for just tabs; I agree that tab trees are limited for the long-term storage needs. I just think bookmarks are too crippled to serve as the solution for those needs.

> Web page state is supposed to either be stored server-side or client-side using cookies or HTML5 local storage - which persist after the tab is closed.

Supposed doesn't matter to me, frankly. A solution for me must work for most sites, regardless of whether the web developers of those sites do the "supposed" or not.

But even if they did, those cookies and local storage aren't tied to the bookmarks, so I can't rely on them. Chances are they'll expire much sooner, plus they generally only work on the same machine where they were created, which in the long-term may not be the same I'll be using later.

And the ultimate state loser still applies: URLs rot, and bookmarks rot with them. For long-term storage, they're absolutely not enough. Hence my use of page archiving as files, instead.

> It's extremely unlikely that you're going to have more than a few of these tasks that all absolutely require page state that isn't present in the URL or through local storage and you're accumulating them faster than you can complete them.

Maybe, but I don't care to waste time finding out which pages do or do not have their state in the URL or local storage if I need it. Tabs simply work.

Re:Flow browser passes the Acid tests by dorgo on Sunday June 14, 2020 @05:30AM (#23516269)
>Could you give a few examples of this? I still can't think of anything particularly common that would reasonably justify more than a dozen tabs at once...

I clicked an internal link in this thread (in firefox) and after it loaded (1s) I clicked the back button. 0.7 seconds later I was back but not at the same position. So I had to scroll to find the position to continue to read. I can save 0.7s load time + 5s or 10s of search by opening a new tab instead.

Disadvantages of single tab usage (off the top of my head):

- additional load time

- formular inputs should be preserved, but I wouldn't count on it.

- highlighted text is not highlighted any more

- server can send me another version (or nonthing 404). So I lose the content alltogether.

-

Re:Flow browser passes the Acid tests by fouric on Sunday June 14, 2020 @02:11PM (#23519859)
That's not an actual example, though. That's an action you took. I was asking for a concrete example of a task (e.g. doing your online banking) that reasonably requires more than a dozen tabs (metaphorically - change that to fit your RAM usage, the actual number matters less than "unbounded" which is what many people use, or the number that would consume all the RAM on your device).
Re:Flow browser passes the Acid tests by nitrogen on Sunday June 14, 2020 @03:31PM (#23520602)
Tabs and windows are a very convenient UI for maintaining state. Browsers aren't used just to complete one "task" at a time. The "job to be done" isn't "do online banking" or "buy a bike", it's "organize active information". Across virtual dssktops you might have a "finance" window during tax season with several different sites, a window for each ongoing project with dozens of references queued for each, a window for comms (email, chat, social, etc) with half a dozen tabs, a window for news with all the day's threads in tabs, a window of "TODO" tabs with things to buy, a window for gaming, etc.
Re:Flow browser passes the Acid tests by andrekandre on Saturday June 13, 2020 @08:55PM (#23514211)
> Could you give a few examples of this? I still can't think of anything particularly common that would reasonably justify more than a dozen tabs at once...

as an example, someone asks "hey can you update the appstore screenshots" and while i may still have appstore open on anothet tab, ill open a mew one just for that task, then later somone asks, hey whats up with jira ticket 1234, now i already have 3 tickets open in jira, and i dont wanna disturb those, somill open another tab, same with online docs like confluence, or web searches on google... at some poont the overwhelming number of tabs themselves get to be too much, so clearing context to yet-another-tab, is a way of coping i think...

i see this all the time in group meetings btw

> I'm working on a piece of software that goes several levels beyond what browsers currently offer for information organization, and (per the topic)

that sounds cool. one idea ive had for a while is that sites (like confluence ot jira, or gdocs) are basically apps, so they should be treated as such and automatically grouped together (im windows or tabs) just like native apps...

Re:Flow browser passes the Acid tests by nieve on Sunday June 14, 2020 @01:46AM (#23515417)
> However, for the browsers that we have now, bookmarks are much better for organization than tabs

By "browsers we have now" you clearly mean "Chrome, the only browser I care about". Firefox can handle literally thousands of tabs with lower memory than Chrome using one or two dozen due to different trade-offs. Very few people ever use that many, but the presumption that no better should be done on the memory front because your favorite doesn't manage it isn't supported by the facts.

Bookmarks aren't used in the same way as tabs by most people and it's telling that your workflow so easily conflates them that you're making criticisms based the rest of us using them differently. I get the impression that what you want bookmarks for would be better done with tab groups for most people? There are certainly a decent number of happy OneTab users out there who're probably closer to your preferred interface than the rest of us, but even on Firefox its userbase is minuscule.

Re:Flow browser passes the Acid tests by fouric on Sunday June 14, 2020 @02:04PM (#23519796)
> By "browsers we have now" you clearly mean "Chrome, the only browser I care about".

False. I use Firefox for all of my browsing, hate Chrome, and only use Chrome as a whole-browser sandbox for Google products.

> Firefox can handle literally thousands of tabs with lower memory than Chrome using one or two dozen due to different trade-offs.

Yes, and I'm arguing that that's a tradeoff and that's a good thing based on the intent of tabs.

> the presumption that no better should be done on the memory front because your favorite doesn't manage it

Neither did I say that no better should be done, nor do I actually believe that. Presumptuous today, aren't we.

> isn't supported by the facts.

The facts are that tabs are intended to be a working set and are optimized for that. If you don't use them as such, you're going against the design of the tool and expecting it to do well, which is insane. It's equivalent to using files on a filesystem like RAM (expecting extremely quick access and no wear over time) and then complaining when they're slow and your SSD wears out in a few weeks.

> Bookmarks aren't used in the same way as tabs by most people and it's telling that your workflow so easily conflates them that you're making criticisms based the rest of us using them differently.

Correct, because they aren't different. Bookmarks are intended to be used for saving and organizing things for the long term. Tabs are intended to be used for actively working on a task. They're two different things. Thinking that the case where you reasonably want to work on a task that requires dozens of tabs to be open, all at once, all on the same topic, and you switch between all of them very frequently is a common case is completely unsupported by evidence, and logically incoherent.

This has nothing to do with my workflow, and everything to do with the design intent of the tool, and proper use of the tool. Again, see the example about using disk as working memory.

> I get the impression that what you want bookmarks for would be better done with tab groups for most people?

Again, this is something that bookmarks are much, much better optimized for than tabs. Bookmarks can exist in folders - which are probably like tab groups, but first-class, and much better supported - and tabs cannot. Bookmarks can be tagged, and tabs cannot. Bookmarks can be exported to a file, and tabs cannot. Bookmarks can be renamed, and tabs cannot. Bookmarks are straight-up better at their job then tabs are. This is not "better done with tab groups for most people" - this is "worse than tab groups for everyone".

To summarize: working memory is not the same as long-term storage (in the human brain, in operating systems, in physical desks, in the browser, and everywhere). Tabs are for working memory, and optimized for that. Bookmarks are for long-term storage, and optimized for that. Bookmarks are objectively better than tabs for long-term storage in non-performance metrics (can be organized using folders and tags, can be exported/imported, can be renamed) and performance metrics, and you and everyone else who insist on using tabs like bookmarks are (1) doing yourselves a disservice by using the tool wrong and suboptimally and (2) doing everyone else a disservice by demanding that the tool literally be made less optimal to fit your incorrect use of it.

Re:Flow browser passes the Acid tests by int_19h on Tuesday June 16, 2020 @07:52PM (#23545812)
What makes you believe that's the "design intent"?
Re:Flow browser passes the Acid tests by kinleyd on Saturday June 13, 2020 @11:55PM (#23514969)
Yes, I think a better way to quickly save and organize bookmarks, addressing needs for both immediate use and for long-term reference would be a good way forward.
Re:Flow browser passes the Acid tests by andromeduck on Sunday June 14, 2020 @09:06AM (#23517389)
Yeah and this is what makes a lot of mobile forms/fields so incredibly annoying. You're filling out a form or something and need to look something up, do a search, go check check another tab or app, switch back and sorry we just killed that context, wanna start over?
Re:Flow browser passes the Acid tests by kerkeslager on Saturday June 13, 2020 @11:52PM (#23514955)
> Finally, there are very few cases where you should have a large number of Chrome tabs open anyway.

How users use the program determines how the program should be implemented, not the other way around.

Re:Flow browser passes the Acid tests by nostrademons on Sunday June 14, 2020 @01:25AM (#23515333)
We actually measured this when I was at Google. It turns out most Googlers and users of HN are weird - having lots of tabs open is the exception, not the rule, but it's an exception that's very common among the techie demographic that constitutes Google employees and people who criticize them. The average web user doesn't know what tabbed browsing is, and then another large plurality uses only a handful (~2-3) of tabs. The percentage of web users who have 10+ tabs open is in the low single digits.
Re:Flow browser passes the Acid tests by cxr on Sunday June 14, 2020 @04:25PM (#23521014)
> The average web user doesn't know what tabbed browsing is

My anecdotal observations are that this often causes extreme number of tabs. I've seen multiple examples from social media in the last month of people scrolling through their mom's (/little brother's/etc) phone, showing hundreds of tabs, but usually all duplicates of the same dozen or so. I remember seeing similar things firsthand (but not to as great an extent) when the first generation iPad came out. And I've also witnessed the same in offices, where doing something in an app or an existing page will arbitrarily open a new window or tab, leading to an explosion of windows and tabs all hidden beneath the IE11 icon in the Windows taskbar.

By all signs, it seems true that (a) average people don't know what tabs are, and (b) they have a lot of them. So it makes me wonder about your methodology. I used to be a Mozillian, and I remember the less-than-rigorous excuses that Firefox UX folks reached for when backfilling justifications for their design whims.

Re:Flow browser passes the Acid tests by afiori on Sunday June 14, 2020 @05:26PM (#23521538)
> I've seen multiple examples from social media in the last month of people scrolling through their mom's (/little brother's/etc) phone, showing hundreds of tabs, but usually all duplicates of the same dozen or so.

Honestly this is the only reasonable way to use tabs on a mobile browser. There is almost no drawback of keeping them and closing them is a chore. I get it sounds like the typical "boomers using the internet" but given that you should expect old inactive tabs to unload anyway having even hundreds of tabs open is a detail.

Re:Flow browser passes the Acid tests by TeMPOraL on Sunday June 14, 2020 @06:41AM (#23516623)
That's a very interesting result - in particular, because it doesn't agree with my anecdotal evidence of almost everyone I know outside of tech; I can't think of a single person whose computer I've seen that doesn't keep >10 tabs open in perpetuity, even across restarts.
Re:Flow browser passes the Acid tests by kerkeslager on Monday June 15, 2020 @08:51AM (#23526731)
Interesting. Depending on the percentages and methodology, that sounds like a reasonable argument for deprioritizing multiple tab performance.

That said, what you're saying is, "In practice, users don't have a lot of tabs open", which is very different from what I was responding to, which was "users shouldn't have a lot of tabs open".

Re:Flow browser passes the Acid tests by arghwhat on Saturday June 13, 2020 @06:57PM (#23513555)
> Memory is not very useful when you're not using it, and has a very low cost when you are ... CPU cycles cost power when you use any amount ...

Of course important to remember that increased memory utilization results in increased CPU utilization. The range of degradation is quite wide: Increased cache misses (which cost a significant number of cycles), access patterns not in line with the prefetcher, and increased TLB misses.

It's for good reason that one of the most potent optimization techniques for hot code is to reduce the memory footprint and memory access.

Re:Flow browser passes the Acid tests by fouric on Saturday June 13, 2020 @07:38PM (#23513815)
I specifically said that I was talking about an engineering tradeoff, however - that is, when you have to choose between one or the other. Excluded from that is the possibility of improving both memory and CPU consumption at the same time - that means that you haven't hit the edge of the curve, so to speak.
Re:Flow browser passes the Acid tests by arghwhat on Tuesday June 16, 2020 @04:03AM (#23536910)
You wrote it as an "pick memory utilization or CPU utilization", stating memory as being practically free. I just wanted to correct that by saying that its utilization is very expensive for the CPU.

Rather the trade off you're thinking of is "caching vs. realtime computation" rather than just "memory vs. cpu". Outside caching, it's pretty universal that more memory utilization just means poorer performance, both in wallclock time and in CPU utilization.

Re:Flow browser passes the Acid tests by limomium on Monday June 15, 2020 @04:12AM (#23525030)
> Memory is not very useful when you're not using it

It's also not very useful when someone else is hogging all of it! There is an opportunity cost to the user and other programs. It is supremely selfish to only think of oneself, and reserve all the common resources because "well it was just laying around".

I PAY for the capacity in case I NEED it, not for some bloated browser to snorf it all up because they can't be assed to write reasonable software.

Re:Flow browser passes the Acid tests by wolco on Saturday June 13, 2020 @10:20PM (#23514600)
Multiple open tabs is such a common scenerio.

A common use-case: I visit a site I open a new link in a separate tab. Those tabs are visited later.

Having gmail open, slack web client, jira, git and the dev and prod versions of a site I'm building is a common scenerio.

Re:Flow browser passes the Acid tests by wadkar on Sunday June 14, 2020 @03:21AM (#23515753)
Re: large number of tabs

Use the great suspender extension; my friend in academia thanks me every single time we meet. And now I see them have 4 chrome windows open with each having ~20+ tabs in it!!!

For them everything happens in browser, its synced and the great suspender lets them run that monstrosity without choking their MacBook Airs

Re:Flow browser passes the Acid tests by TeMPOraL on Sunday June 14, 2020 @06:39AM (#23516616)
Doesn't this kill the primary benefit of tabs, namely that the content is already loaded and you don't need to hit the server again?
Re:Flow browser passes the Acid tests by account42 on Tuesday June 16, 2020 @10:16AM (#23539385)
Kind of, but if you have enough tabs the cost may become to high. I my FF set up so that tabs are suspended only after a generous time limit and have also excluded some sites so that they are never suspended. Would be nice to be able to suspend the tabs to disk instead of throwing the state away completely.
Re:Flow browser passes the Acid tests by ahed on Tuesday June 16, 2020 @09:36AM (#23538964)
Re:Flow browser passes the Acid tests by Someone on Saturday June 13, 2020 @04:31PM (#23512431)
“Memory is not very useful (modulo filesystem caches) when you're not using it, and has a very low cost when you are (extremely tiny power consumption”

One problem is that CPUs have various ways to use less power or even switch off parts when not in use, but you always pay the same for RAM.

For battery-operated devices that sleep most of the time such as smartphones, that means being careful with memory usage is the way to go. I think that’s part of the reason iPhones ship with less RAM then Android devices (reference counting needs less RAM than garbage collection for the same performance level)

Re:Flow browser passes the Acid tests by fouric on Saturday June 13, 2020 @07:50PM (#23513876)
I'm specifically referring to applications (like Chrome) that you use interactively in the foreground. When using one of these applications, your device is not off or in sleep mode - it is on, you are interacting with it, and it is either consuming more CPU or less. A memory-hungry, CPU-light design drains your battery more slowly than one the other way around.

Additionally, the extra power cost of adding more RAM to a device is very low relative to even using 25% of total CPU TDP. [1] gives 3W per DIMM for DDR3 (which is an upper bound, given that LPDDR3 will consume far less power while fully on, let alone in deep sleep mode) and [2] gives 2.5W for DDR2.

Edit: aha, found a paper[3] on RAM power consumption in a phone. Far less than 5% in either "suspended" or "idle" states, under 10% in almost every other benchmark, and universally lower than CPU power consumption.

[1] http://www.buildcomputers.net/power-consumption-of-pc-compon...

[2] https://superuser.com/questions/40113/does-installing-larger...

[3] https://www.usenix.org/legacy/event/atc10/tech/full_papers/C...

Re:Flow browser passes the Acid tests by kortex on Saturday June 13, 2020 @09:20PM (#23514338)
Unaffiliated plug: The Great Suspender is really handy for automatically suspending unused tabs after X minutes for us taboholics.
Re:Flow browser passes the Acid tests by ksec on Sunday June 14, 2020 @07:31AM (#23516894)
And for those using Safari, you could simply restart your browser and most of the tabs will not be loaded until you click on it.
Re:Flow browser passes the Acid tests by Veedrac on Saturday June 13, 2020 @09:10PM (#23514287)
Having seen the realtime-rendered Horizon Forbidden West trailer, justifying Chrome's ‘smooth’ animations this way is like stepping into a parallel world.

I can't even scroll Twitter without stutter on my hefty gaming laptop, my browser (the whole thing! not just the tab!) often freezes for 10+ seconds when first rendering a page, and toggling Reddit's sidebar takes half a second.

To the extent Chrome's anything can be deemed ‘smooth’, it's because computers are fast, not because they made some clever space-time trade-off.

Re:Flow browser passes the Acid tests by fouric on Sunday June 14, 2020 @02:52PM (#23520230)
Twitter and Reddit are both known to be poorly-engineered and ridiculously heavy applications. They're very slow on Firefox, too, and probably any browser you care to use.
Re:Flow browser passes the Acid tests by afiori on Sunday June 14, 2020 @05:29PM (#23521559)
Sometimes I feel like trying to test the reddit infinite scroll and measure GB and CPU% per meter.
Re:Flow browser passes the Acid tests by tryauuum on Sunday June 14, 2020 @10:06AM (#23517719)
What kind of websites need 8GB per tab? I have never had problems with chrome or firefox on my 4GB box.

EDIT: someone in this thread posted this:

  I can't even scroll Twitter without stutter on my hefty gaming laptop, my browser (the whole thing! not just the tab!) often freezes for 10+ seconds when first rendering a page, and toggling Reddit's sidebar takes half a second.
This explains a lot, I (almost) never visit twitter or reddit.
Re:Flow browser passes the Acid tests by jmilloy on Saturday June 13, 2020 @01:15PM (#23510937)
Would be a dream as a user to be able to choose between cpu-optimized or memory-optimized modes.
Re:Flow browser passes the Acid tests by gruez on Saturday June 13, 2020 @01:30PM (#23511054)
browser vendors can barely keep one renderer/javascript engine free of 0days, I can't imagine how secure a browser would be with double the codepaths.
Re:Flow browser passes the Acid tests by eurasiantiger on Saturday June 13, 2020 @04:19PM (#23512349)
Nothing is free of 0days.
Re:Flow browser passes the Acid tests by DaiPlusPlus on Saturday June 13, 2020 @04:33PM (#23512450)
hello_world.c is still pretty secure, right?
Re:Flow browser passes the Acid tests by traverseda on Saturday June 13, 2020 @06:59PM (#23513582)
Not since spectre.
Re:Flow browser passes the Acid tests by thih9 on Saturday June 13, 2020 @01:31PM (#23511060)
I wish this was a display option instead.

I.e. “Disable animations in all web pages (gracefully)”.

Re:Flow browser passes the Acid tests by ficklepickle on Saturday June 13, 2020 @01:53PM (#23511224)
There is a CSS media query for that: prefers-reduced-motion

Now whether any sites actually make use of it is another matter. Also I don't know how the user would enable it. Perhaps an OS-specific, system-wide setting like dark mode.

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

Re:Flow browser passes the Acid tests by dullgiulio on Saturday June 13, 2020 @02:13PM (#23511383)
Again, disabling features is a feature given to the site developer, not to the visitor, who's actually running the code.

It would be so much better if browsers were User Agents and respected user settings before the will of the site creator.

Re:Flow browser passes the Acid tests by robin_reala on Saturday June 13, 2020 @03:41PM (#23512090)
They are? * { animation-play-state: paused !important; transition-duration: 0s !important; }
Re:Flow browser passes the Acid tests by duskwuff on Saturday June 13, 2020 @04:32PM (#23512439)
> Also I don't know how the user would enable it.

In Apple products, it's exposed as an accessibility option:

macOS: https://support.apple.com/guide/mac-help/reduce-screen-motio...

iOS: https://support.apple.com/en-us/HT202655

tvOS: https://support.apple.com/guide/tv/reduce-screen-motion-atvb... (which also disables autoplaying previews!)

Re:Flow browser passes the Acid tests by robin_reala on Sunday June 14, 2020 @05:13AM (#23516179)
A friend integrated it into Bootstrap for default animations last year, so I’d guess that a lot of sites are using it.
Re:Flow browser passes the Acid tests by ahed on Tuesday June 16, 2020 @09:49AM (#23539076)
only for Safari on macOS and iOS
Re:Flow browser passes the Acid tests by robin_reala on Thursday June 18, 2020 @04:19AM (#23560953)
Re:Flow browser passes the Acid tests by cercatrova on Saturday June 13, 2020 @01:45PM (#23511169)
Re:Flow browser passes the Acid tests by tinco on Saturday June 13, 2020 @01:22PM (#23510987)
When would you ever not opt for a cpu optimized mode? Cpu's can't get faster, and you can always get more memory.
Re:Flow browser passes the Acid tests by rubyn00bie on Saturday June 13, 2020 @01:44PM (#23511158)
I, rather unfortunately for myself I suppose, find most animations on the web or even CPU intensive sites to be... well, quite frankly, piles of shit.

I would opt to stop letting web page authors just mangle my CPU cycles because they've opted to poorly animate an SVG or some HTML element. If anything I'd prefer each got a CPU budget and that was all they could use, unless they request more CPU time from the user, then voila! People who want to be annoyed can be, and the rest of us can go back to "browsing the web."

Re:Flow browser passes the Acid tests by jabirali on Saturday June 13, 2020 @01:44PM (#23511154)
A perhaps more useful tradeoff would be if one could disable a subset of CSS/JS with a simple switch in the settings, so e.g. transition animations are skipped but the webpage is otherwise readable.

I think I have yet to see a webpage that uses animations in a way I enjoy, even when they’re smooth. (The same goes for most PowerPoint transitions and window manager animations...)

Re:Flow browser passes the Acid tests by alpaca128 on Saturday June 13, 2020 @03:20PM (#23511921)
I also go back to switch off animations wherever I have the choice. Some animations look really good but long term they all just feel like fancy input delays.
Re:Flow browser passes the Acid tests by robin_reala on Saturday June 13, 2020 @03:42PM (#23512101)
For most people you can’t get more memory without swapping in your device for a newer one. All mobile phones, all tablets, and a good chunk of laptops have soldered in memory with no expansion possibilities.
Re:Flow browser passes the Acid tests by adrianN on Sunday June 14, 2020 @01:12AM (#23515281)
Getting a faster CPU is about as difficult as getting more memory for almost everybody, because people need to buy new machines to do so. Either because they own a machine that can't be upgraded (hello soldered ram), or because they don't have the technical skills to do so.

Personally I'd rather wait longer for things to complete than have my whole system grind to a halt because it starts swapping like crazy.

Re:Flow browser passes the Acid tests by vbezhenar on Saturday June 13, 2020 @10:29AM (#23509588)
I wonder did someone try to dissect where that Chrome memory is going to?

I can run Intellij Idea: Java IDE, load project with thousands of files into it and it won't eat 8 GB.

I understand that Chromium is maintained by extremely talented developers and all obvious improvements were made, so that memory usage is probably necessary. But I still wonder how is it possible. Gigabyte of RAM is a lot.

Re:Flow browser passes the Acid tests by thdrdt on Saturday June 13, 2020 @11:12AM (#23509971)
Not an exact answer to your question but there are a lot of things taking more memory than you would think. Today websites contain high res images. Well, you might say, 800KB isn't much. But that is the compressed size. The bitmap data is way bigger. All this data has to be kept in memory.

But yeah, 8GB is unbelievable. I have no clue why Chrome needs this.

Re:Flow browser passes the Acid tests by aeyes on Saturday June 13, 2020 @12:38PM (#23510656)
> I can run Intellij Idea: Java IDE, load project with thousands of files into it and it won't eat 8 GB.

I don't have the same experience, PyCharm is absolutely killing my machine and I always have it in Power Save mode. Sure, it isn't eating 8GB but that is because the JVM by default doesn't have that much available. I had to raise the memory limit considerably to be able to open my projects without it hanging.

Re:Flow browser passes the Acid tests by jomohke on Saturday June 13, 2020 @04:58PM (#23512672)
That’s not normal.

What plugins do you have installed? Maybe one is slowing it down?

And perhaps run “clear caches / restart” just in case there’s cache corruption

I run it fine on a Linux machine that has 4GB ram total — I’m curious how much memory you’re talking about.

Re:Flow browser passes the Acid tests by Yoric on Saturday June 13, 2020 @12:22PM (#23510514)
I don't know about Chrome but in Firefox if you want to know, go to link about:memory. Caveat: it's very technical :)
Re:Flow browser passes the Acid tests by moogly on Sunday June 14, 2020 @03:57AM (#23515882)
That page ("Stats for nerds") was removed from Chrome ages ago. And before it was removed, it was a pretty petty thing since it spent time and effort on also showing memory usage from other currently running browsers.
Re:Flow browser passes the Acid tests by moron4hire on Saturday June 13, 2020 @12:32PM (#23510600)
I think it's a mistake to think that, just because someone works at Google or on Chromium, they are necessarily "talented" developers. They're just the developers that are working on Chromium. Normal people like the rest of us.
Re:Flow browser passes the Acid tests by vntok on Sunday June 14, 2020 @04:54AM (#23516099)
Google has a ~0.2% hiring acceptance rate, which is much more selective than the vast majority of software companies. For Google developers to be "normal people", the hiring process would have to be absolutely terrible.
Re:Flow browser passes the Acid tests by Beldin on Saturday June 13, 2020 @01:04PM (#23510838)
On a related note, i once came across the notion that free memory isn't doing anything for you.

It's kind of obvious and does not at all explain chromium's lower bound of memory usage. But: if Chromium runs better with more memory and no other process is using it: please take it!

That is what it's there for, after all.

Re:Flow browser passes the Acid tests by gibolt on Saturday June 13, 2020 @01:31PM (#23511065)
This is fine, until another application needs it. Then it becomes a power struggle for the throne, and both sides lose.
Re:Flow browser passes the Acid tests by vbezhenar on Sunday June 14, 2020 @11:53AM (#23518632)
That's not correct for any modern OS. Free memory is used as a disk cache, so your computer is significantly faster with more free memory.

Well, not as significantly now, with SSD everywhere, but still faster.

Re:Flow browser passes the Acid tests by Dylan16807 on Saturday June 13, 2020 @04:47PM (#23512567)
If it would actually detect that, it could be great.

But I have a chromebook with 4GB of ram, and it often struggles to keep a particular set of 3 expensive tabs open because it runs out. It's definitely not reacting to memory pressure by being less greedy.

Re:Flow browser passes the Acid tests by plerpin on Saturday June 13, 2020 @10:30PM (#23514631)
Your pages might have huge JS heaps allocated or contain supersampled assets.
Re:Flow browser passes the Acid tests by rgrieselhuber on Saturday June 13, 2020 @10:36AM (#23509658)
This topic always reminds me of the work of Paul Virilio, on how system design often (deliberately or not) impedes our own natural processing capabilities by slowing us down / wasting our time.
Re:Flow browser passes the Acid tests by londons_explore on Saturday June 13, 2020 @12:00PM (#23510347)
You can hit F12 in a chromium based browser and hit the memory tab and find out where all the RAM is going...
Re:Flow browser passes the Acid tests by pwdisswordfish2 on Sunday June 14, 2020 @04:41PM (#23521160)
My Chromebook doesn't have an F12 key.
Re:Flow browser passes the Acid tests by MauranKilom on Saturday June 13, 2020 @12:27PM (#23510557)
Also works in FF.
Re:Flow browser passes the Acid tests by amelius on Saturday June 13, 2020 @11:54AM (#23510291)
All (browser) developers should be using a Pi as their main machine.
Re:Flow browser passes the Acid tests by iforgotpassword on Saturday June 13, 2020 @01:30PM (#23511059)
Yes, developers in general. Force them to use their own stuff on laptop HDDs, mounted via NFS.

Gnome and KDE folks. Although I stopped using either of those so I don't care.

Re:Flow browser passes the Acid tests by toast0 on Saturday June 13, 2020 @03:26PM (#23511969)
Over remote X too, please. Doesn't have to be very remote (but you know, bonus points if it is)
Re:Flow browser passes the Acid tests by mrlonglong on Sunday June 14, 2020 @11:12AM (#23518240)
Me too. I'm absolutely dreading moving to Wayland for this reason since there are issues using it over the network.
Re:Flow browser passes the Acid tests by bitwize on Saturday June 13, 2020 @12:56PM (#23510775)
The W3C and the WHAT, too.

I keep obsolete computers and phones around to test with.

Re:Flow browser passes the Acid tests by arexxbifs on Saturday June 13, 2020 @10:12AM (#23509458)
I used a Raspi 3B as my main desktop for a while a couple of years back. It worked fine for most things I wanted to do, except for web browsing. NetSurf was good enough for most things, but I had to use Chromium for online banking. It was slow, but it worked. Sure, 1 gig is a bit cramped these days but the problem in general are the web sites, not the browsers.
Re:Flow browser passes the Acid tests by iforgotpassword on Saturday June 13, 2020 @01:33PM (#23511082)
I'd say it's a vicious circle. Chrome folks look at real world performance and optimize for that. Web devs see their site performing better and add more shit until their dev machine is almost bogging down. Rinse and repeat.
Re:Flow browser passes the Acid tests by entha_saava on Sunday June 14, 2020 @06:24AM (#23516541)
Yeah it is mostly web devs being crap. No problem with sites like HN.
Re:Flow browser passes the Acid tests by stephen_g on Sunday June 14, 2020 @01:01AM (#23515240)
I tried installing a modern Xubuntu desktop on a 3B+ a few weeks ago. You can hardly even open Chromium or Firefox these days (maybe with a lighter desktop it would be slightly better)...
Re:Flow browser passes the Acid tests by arexxbifs on Sunday June 14, 2020 @04:55AM (#23516103)
I think the best choice is still Raspbian. I was running Raspbian+Fvwm2 at the time.
Re:Flow browser passes the Acid tests by mpweiher on Saturday June 13, 2020 @03:43PM (#23512107)
> but software is bloating faster

This is called Wirth's Law: Software gets slower faster than hardware gets faster.

https://en.wikipedia.org/wiki/Wirth%27s_law

Re:Flow browser passes the Acid tests by zdragnar on Saturday June 13, 2020 @08:16PM (#23514005)
That depends on what you're doing with it, I suppose- chromebooks typically don't have that much RAM and are usually sufficiently powerful for most any website. My wife uses one exclusively for YouTube, Netflix, facebook etc.

Pretty much the only thing we've seen it stutter on is browsing very high res images taken with a high end camera off of a USB stick.

Re:Flow browser passes the Acid tests by c-smile on Saturday June 13, 2020 @10:16AM (#23509492)
For that matter Sciter is pretty happy to run (render HTML/CSS and executing scripts) on rPI https://sciter.com/raspberry-pi-4/

So that's about architecture of the Chromium - multiple processes (not even threads) and IPC between them to render stuff.