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.
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.
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.
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.
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.
So it is not FUD at all.
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...
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.