<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>MereInterest</author><text>&amp;gt; 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&amp;#x27;t support it) and rapid context-switches are inefficient.&lt;p&gt;I agree that the human brain doesn&amp;#x27;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.</text><parent_chain><item><author>fouric</author><text>&amp;gt;  The reason for Chrome&amp;#x27;s massive memory requirements is that they make memory vs. CPU&amp;#x2F;performance&amp;#x2F;security tradeoffs on a regular basis, and usually make them against memory.&lt;p&gt;This is generally a good trade. Memory is not very useful (modulo filesystem caches) when you&amp;#x27;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 &amp;quot;my RAM is at 75% usage&amp;quot;.&lt;p&gt;Additionally, Chrome&amp;#x27;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 &lt;i&gt;more&lt;/i&gt; expensive. On more expensive devices, you have all the memory you need for Chrome anyway, so you&amp;#x27;re just getting better latency.&lt;p&gt;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&amp;#x27;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&amp;#x27;re simply decreasing your productivity and capacity for focus. Even when doing multi-disciplinary research, there are a &lt;i&gt;ton&lt;/i&gt; 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 &lt;i&gt;darn bookmarks instead of tabs like they were intended to be used&lt;/i&gt;.&lt;p&gt;(of course, in an ideal world, all web browsers would use absolutely no memory or processing power whatsoever - I&amp;#x27;m just defending this particular engineering tradeoff)</text></item><item><author>nostrademons</author><text>There was a meme when I was at Google (~2012) that went:&lt;p&gt;&amp;quot;What would you do if you had 16GB of RAM?&amp;quot;&lt;p&gt;&amp;quot;I&amp;#x27;ll tell you what I&amp;#x27;d do with that.  2 Chrome tabs at the same time.&amp;quot;&lt;p&gt;(Superimposed over the scene from Office Space.)&lt;p&gt;(On a more charitable note, I worked with the Chrome performance team on a few occasions.  The reason for Chrome&amp;#x27;s massive memory requirements is that they make memory vs. CPU&amp;#x2F;performance&amp;#x2F;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&amp;#x2F;cascading&amp;#x2F;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.)</text></item><item><author>htk</author><text>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.</text></item><item><author>rattray</author><text>This actually looks pretty interesting.&lt;p&gt;They started out as an SVG engine for set-top boxes (embedded devices running on TV&amp;#x27;s) since browsers at the time weren&amp;#x27;t fast&amp;#x2F;light enough for the underpowered chips in set-top boxes. Then when the devices got better chips, they realized perf still wasn&amp;#x27;t good enough for big 4k screens – and that multicore rendering could help.&lt;p&gt;So they&amp;#x27;ve implemented a full HTML&amp;#x2F;CSS&amp;#x2F;JS browser from scratch, all to take advantage of a multicore architecture (today&amp;#x27;s browsers all render on a single thread) which has enabled (they claim) greater than 4x better framerate during web animations than the stable channels of Chrome&amp;#x2F;Blink and Safari&amp;#x2F;Webkit. Oh, and 60% faster layout on a quad-core machine.&lt;p&gt;They also claim &amp;quot;extremely low memory consumption&amp;quot;, which would be quite appealing to many HN&amp;#x27;ers I think, though that may only be true of their HTML engine and not of the full browser (eg; when using multiple tabs and hungry JS apps).</text></item></parent_chain></comment><story><title>Flow browser passes the Acid tests</title><url>https://www.ekioh.com/devblog/acid</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>andrekandre</author><text>&amp;gt; Finally, there are very few cases where you should have a large number of Chrome tabs open anyway.&lt;p&gt;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...&lt;p&gt;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...&lt;p&gt;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...</text><parent_chain><item><author>fouric</author><text>&amp;gt;  The reason for Chrome&amp;#x27;s massive memory requirements is that they make memory vs. CPU&amp;#x2F;performance&amp;#x2F;security tradeoffs on a regular basis, and usually make them against memory.&lt;p&gt;This is generally a good trade. Memory is not very useful (modulo filesystem caches) when you&amp;#x27;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 &amp;quot;my RAM is at 75% usage&amp;quot;.&lt;p&gt;Additionally, Chrome&amp;#x27;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 &lt;i&gt;more&lt;/i&gt; expensive. On more expensive devices, you have all the memory you need for Chrome anyway, so you&amp;#x27;re just getting better latency.&lt;p&gt;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&amp;#x27;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&amp;#x27;re simply decreasing your productivity and capacity for focus. Even when doing multi-disciplinary research, there are a &lt;i&gt;ton&lt;/i&gt; 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 &lt;i&gt;darn bookmarks instead of tabs like they were intended to be used&lt;/i&gt;.&lt;p&gt;(of course, in an ideal world, all web browsers would use absolutely no memory or processing power whatsoever - I&amp;#x27;m just defending this particular engineering tradeoff)</text></item><item><author>nostrademons</author><text>There was a meme when I was at Google (~2012) that went:&lt;p&gt;&amp;quot;What would you do if you had 16GB of RAM?&amp;quot;&lt;p&gt;&amp;quot;I&amp;#x27;ll tell you what I&amp;#x27;d do with that.  2 Chrome tabs at the same time.&amp;quot;&lt;p&gt;(Superimposed over the scene from Office Space.)&lt;p&gt;(On a more charitable note, I worked with the Chrome performance team on a few occasions.  The reason for Chrome&amp;#x27;s massive memory requirements is that they make memory vs. CPU&amp;#x2F;performance&amp;#x2F;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&amp;#x2F;cascading&amp;#x2F;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.)</text></item><item><author>htk</author><text>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.</text></item><item><author>rattray</author><text>This actually looks pretty interesting.&lt;p&gt;They started out as an SVG engine for set-top boxes (embedded devices running on TV&amp;#x27;s) since browsers at the time weren&amp;#x27;t fast&amp;#x2F;light enough for the underpowered chips in set-top boxes. Then when the devices got better chips, they realized perf still wasn&amp;#x27;t good enough for big 4k screens – and that multicore rendering could help.&lt;p&gt;So they&amp;#x27;ve implemented a full HTML&amp;#x2F;CSS&amp;#x2F;JS browser from scratch, all to take advantage of a multicore architecture (today&amp;#x27;s browsers all render on a single thread) which has enabled (they claim) greater than 4x better framerate during web animations than the stable channels of Chrome&amp;#x2F;Blink and Safari&amp;#x2F;Webkit. Oh, and 60% faster layout on a quad-core machine.&lt;p&gt;They also claim &amp;quot;extremely low memory consumption&amp;quot;, which would be quite appealing to many HN&amp;#x27;ers I think, though that may only be true of their HTML engine and not of the full browser (eg; when using multiple tabs and hungry JS apps).</text></item></parent_chain></comment><story><title>Flow browser passes the Acid tests</title><url>https://www.ekioh.com/devblog/acid</url></story>