Let me respond to this comment from the article:
"""
This is not the case for Chrome: the browser keeps all the cached information indefinitely; perhaps this is driven by some hypothetical assumptions about browsing performance, and perhaps it simply is driven by the desire to collect more information to provide you with more relevant ads. Whatever the reason, the outcome is simple: over time, cache lookups get progressively more expensive; some of this is unavoidable, and some may be made worse by a faulty hash map implementation in infinite_cache.cc.
"""
Chromium (and thereby, Google Chrome) does not cache forever. The author is clearly misled by the infinite_cache.cc file he referenced. That is our experiment file, designed to examine a theoretical "infinite" cache's performance for data gathering purposes. It doesn't actually cache the resources, but just records the keys (basically, the URL). It only runs on a small set of user browser sessions (only for users who opt-in to helping make Google Chrome better and a subset of their browsing sessions).
As my previous Google+ post mentions (thanks for the parent for linking it), we cap the cache size at 320MB. The author is simply factually incorrect about the aforementioned claim.
As for cache performance as the cache gets larger, I fully believe that it gets slower. We have data that backs up this assertion. Of course, larger caches means that more gets cached. And there are ways to restructure the cache implementation to avoid the painful latency on cache misses. While cache misses are indeed a large percent of resource requests, it is misguided to analyze the cost of cache misses in isolation. For the opposite argument about how we should be increasing cache sizes, see Steve Souders' posts: http://www.stevesouders.com/blog/2012/10/11/cache-is-king/, http://www.stevesouders.com/blog/2012/03/22/cache-them-if-yo..., etc.
The caching issues are far more complicated than described in the original post. The data is much appreciated, and we have similar data that we're looking at as we're making our decisions about caching.
To set the cache to only 100MB, you can always use the "--disk-cache-size=104857600" flag.
My issue with chrome is that it eats up a lot more RAM than Firefox. When doing research, I often have 30-50 tabs open. With Chrome my system runs out of physical RAM and starts thrashing. With Firefox, the UI becomes unresponsive due to it's single threaded design.
I wish Chrome would start a Memshrink project like Mozilla did or Mozilla would finish with they started with electrolysis.
On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. One killer is the GPU process often taking 200+MB.
Before giving up, and switching to FF, I tried the --disable-gpu --disable-software-rasterizer switches to disable the GPU process but that prevented videos from playing at full speed.
> My issue with chrome is that it eats up a lot more RAM than Firefox. When doing research, I often have 30-50 tabs open. With Chrome my system runs out of physical RAM and starts thrashing. With Firefox, the UI becomes unresponsive due to it's single threaded design.
Alternatively, since you seem to be a power user, you could consider upgrading your hardware to 8 or 16 GB of memory; it's not that expensive nowadays, and given your power user status, more memory = faster computer experience = higher productivity. Or just more tabs.
[old man mode] Back in the day we upgraded our computers instead of blaming software.
There's no need to answer FUD with FUD: Firefox's UI does not become unresponsive with increasing number of tabs. Certainly not with just 50 anyhow; I do that all the time and never notice a slowdown. The tab-closing animation is less smooth than chrome's however. And while it's certainly true chrome uses more memory per tab, I can't imagine running into that problem very easily even on somewhat outdated hardware. A 4GB system should be able to do 50 tabs normally, and how much more do you need?
I have a quad-core, 8GB machine at work and a dual-core 4GB machine at home. Both are running Win7 64-bit. How much more do I need?
I have noticed slowdown in Firefox's UI on both machines. More important than number of tabs, is CPU usage. For example my HTML5 heavy trading platform often causes the single-threaded Firefox UI to freeze and slowdown on both machines, while I have never noticed Chrome freezing when this site is open.
On the other hand, Chrome's UI runs smooth as butter until either open tabs or other programs bring memory usage to over 90% Physical Memory in the task manger. Recent builds hit that wall a lot quicker than it did a year or so ago.
I am a Firefox users so this is not coming from a bashing Firefox POV. I could open 100 - 200 Tabs in Firefox without problem if i disable Javascript and all Add on.
As soon as you have some heavy JS usage website, even 50 Tabs can slow down the UI. This is on Quad Core Ivy and 8GB Ram with SSD.
The amount of JS on one website now is getting insane. Chrome have similar problem as well like the OP have said. Just a different one.
The FUD is that the # of tabs has anything to do with it. Also, these problems have been getting a _lot_ better with recent releases, which are much better at avoiding blocking the UI thread. It's not perfect, but it's not something you see very often either. Let me put it this way: I can't even remember the last time I've had a UI slowdown, and I use FF on various machine with lots of tabs all the time. (Firebug's still really slow, though).
So when you say "some heavy JS usage" what exactly do you mean? Certainly not stuff like google docs/mail/calendar, and they're all heavy on the JS...
A large part of Chrome's memory usage is due to its process isolation. It's also what makes it more likely to be responsive, even with UI blocking bugs.
I don't know when you changed the behavior, but until a few months ago the cache was infinite. I close friend was unable to use Chrome because it took minutes - yes, minutes - to boot until we found is was a problem related with the huge cache it was maintaining.
No, we have never had an infinite cache. What is more likely is that your friend may have encountered a bug. If he has information on this issue, please file a bug at crbug.com/new and I will be happy to triage it.
Let me respond to this comment from the article: """ This is not the case for Chrome: the browser keeps all the cached information indefinitely; perhaps this is driven by some hypothetical assumptions about browsing performance, and perhaps it simply is driven by the desire to collect more information to provide you with more relevant ads. Whatever the reason, the outcome is simple: over time, cache lookups get progressively more expensive; some of this is unavoidable, and some may be made worse by a faulty hash map implementation in infinite_cache.cc. """
Chromium (and thereby, Google Chrome) does not cache forever. The author is clearly misled by the infinite_cache.cc file he referenced. That is our experiment file, designed to examine a theoretical "infinite" cache's performance for data gathering purposes. It doesn't actually cache the resources, but just records the keys (basically, the URL). It only runs on a small set of user browser sessions (only for users who opt-in to helping make Google Chrome better and a subset of their browsing sessions).
As my previous Google+ post mentions (thanks for the parent for linking it), we cap the cache size at 320MB. The author is simply factually incorrect about the aforementioned claim.
As for cache performance as the cache gets larger, I fully believe that it gets slower. We have data that backs up this assertion. Of course, larger caches means that more gets cached. And there are ways to restructure the cache implementation to avoid the painful latency on cache misses. While cache misses are indeed a large percent of resource requests, it is misguided to analyze the cost of cache misses in isolation. For the opposite argument about how we should be increasing cache sizes, see Steve Souders' posts: http://www.stevesouders.com/blog/2012/10/11/cache-is-king/, http://www.stevesouders.com/blog/2012/03/22/cache-them-if-yo..., etc.
The caching issues are far more complicated than described in the original post. The data is much appreciated, and we have similar data that we're looking at as we're making our decisions about caching.