15 ms·

A closer look at the performance of Google Chrome

318 points by mrjbq7 14y ago

Revisor 14y ago
Two days later and this article doesn't exist. So much for link rot.
makimoto 14y ago
Did anyone save this offline? it's no longer available
33a 14y ago
The only real wtf here is the history issue. The rest of the stuff -- especially the "antiquated" process isolation -- seem like reasonable trade offs. Switching to a better hash implementation should solve 90% of the performance problems.
comex 14y ago
The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to do anything at all. I don't know any other projects that do what NaCl does, so regardless of whether Google should switch to pure NaCl for sandboxing, if they did, it would be innovation, not scrapping an antiquated technology. As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.
- stcredzero 14y ago
  > The claim that process isolation is "antiquated" is absurd Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.
  - loeg 14y ago
    I don't know about these claims — just because most OS research is now 20+ years old doesn't mean that a result, process isolation, is antiquated. You likely use a very modern operating system with process time-sharing (1964) using virtual memory (1950s/1960s) and so many other results of OS research from 30+ years ago… This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.
- zobzu 14y ago
  Yup, I think some people don't realize why processes exist and what they're here for. It just looks like a concept that we've been using for a long time so, "it must be too old and be replaced", without understanding _how_ it works and _why_ it's there.
  - gtirloni 14y ago
    As everything in IT.
- cpeterso 14y ago
  Firefox uses a sandbox process for plugins like Flash. Mozilla implemented per-tab processes, a project called Electrolysis, but it would break many popular add-ons. Firefox OS is able to use process isolation, through, because it doesn't need to support legacy add-ons.
  - comex 14y ago
    Really? I haven't heard a single thing about Electrolysis in a long time, except I remember reading somewhere recently that it was abandoned. I'm happy to hear that Firefox OS is using it; still, keeping legacy add-ons working seems like a bad reason to stop pursuing such an important security feature on the desktop.
barista 14y ago
A quote worth noting from the article: "Some of these issues - such as the "infinite history" or the antiquated style of process isolation - may be driven by Google's business needs, rather than the well-being of the Internet as a whole. Until this situation changes, our only recourse is to test a lot - and always have a backup plan."
- lenazegher 14y ago
  This glosses over how anti-user infinite history is. The problem of the ever-expanding cache is annoying but easy to deal with - Ctrl+Shift+Del, select only "cache", then "obliterate since the beginning of time". But if you follow this procedure with your browsing history, your (or at least, my) browsing experience is significantly degraded because all your URL autocompletes are gone, at least until you re-visit all your regular sites. You can tell chrome to delete, say, just your browsing history from the last week, but that doesn't help you when what you want to do is delete all browsing history except that from the last week (to preserve your autocompletes). It's a real PITA.
  - wonderzombie 14y ago
    https://news.ycombinator.com/item?id=5282234 https://news.ycombinator.com/item?id=5282234 The cache is not infinite.
- cpleppert 14y ago
  In what possible world could process isolation be driven by business needs? For that matter to describe it as being 'antiquated' is rather bizarre. Every modern browser is moving in that direction including IE10 for security and performance reasons. For that matter, I have no idea what 'infinite history' means, every browser records history and I have no clue how that could possibly impact performance in the slightest.
aristidb 14y ago
I don't buy the claim that process isolation is superseded by NaCl-style validation.
- cpleppert 14y ago
  I agree... You can only validate what is presented to you; a hacker won't kindly hand you a piece of code to run after exploited a hole and ask you to verify it. It also rather circuitous, browsers already verify what they are executing.
zobzu 14y ago
So uhm, it seems like firefox is faster than chrome after a week of use :p
- ceautery 14y ago
  Unless you clear your cache, in which case, in addition to being more secure, Chrome is faster.
  - mbetter 14y ago
    Except when you are typing a URL.
    - spoiler 14y ago
      Are you talking about performance issues as in visual lag, or performance issues as in "the list is empty for a while", because I experience neither, but a friend of mine had issues where no suggestions would show up for a while, but he relied upon them for some reason, and it annoyed him.
      - mbetter 14y ago
        I'm talking about a cache clear blowing out autocomplete history.
  - LeonidasXIV 14y ago
    Why is Chrome more secure? Did I miss a memo? I was under the impression that Firefox security issues are fixed in a pretty decent manner.
    - mtgx 14y ago
      Because of tab sandboxing.
    - spoiler 14y ago
      To be honest I just trust chromium (and chrome) more. I am not even a sure why. Sort of gives me a sense of reliability, security and stability. I had performance issues with Firefox in the past, though, but I doubt that's it. I guess what make a me feel all tingly inside is the GUI, which I love.
polskibus 14y ago
Opinion on process isolation is the most controversial statement in the article, but the other claims are more interesting and easier to verify. If the findings are confirmed by others, it will hopefully drive webkit/chromium ecosystem towards improvement.
veb 14y ago
This is probably off-topic, but I've started using Safari religiously now. When Chrome first came out, it was barebones, fast and did the job. This is what Safari currently feels like, so I'm using it. Fast, stable, and does the job. Now Chrome feels like it's just another bloated browser. Which is slow, and hogs my computer. </opinion>
- webwanderings 14y ago
  As I recall, they stopped updating the browser for Windows after certain version. So comparing Safari to Chrome seems misplaced in this context.
  - scholia 14y ago
    If he uses Safari, I'd assume he has a Mac....
    - spoiler 14y ago
      Well, I used Safari before Chrome, came out... Firefox was dreadfully slow on my old computer. :(
      - scholia 14y ago
        Well, I said "uses" not "used" ;-)
- stock_toaster 14y ago
  I admit to liking Safari, and enjoy the seamless experience (on a mac), but I am a bit hesitant to switch completely given some of the things Safari apparently lacks in the realm of security. As an example, I don't believe Safari currently supports HSTS or cert pinning. Both Chrome and Firefox do.
- diggan 14y ago
  What in Chrome feels like bloat? If you don't install any extensions but adblock plus, Chrome feels kind of minimalistic. The only problem I have with Chrome is that I need to clear cache and history quite often but my computer sucks...
jgrahamc 14y ago
This philosophy is embraced by the developers working on WebKit: in fact, the code responsible for rendering a typical web page averages just 2.1 effective C++ statements per function in WebKit, compared to 6.3 for Firefox - and an estimated count of 7.1 for Internet Explorer. What is an "effective C++ statement"? That's a really odd measure and I can't get my head around it.
- fijal 14y ago
  It's marketing bullshit. He probably wrote a statement in C++ and measured the time it takes to execute, I have no idea (also impossible to know what sort of statement). numbers suggest around 2% accuracy (7.1), that's pretty impressive given that we measure "code responsible for rendering a typical web page" per "function" over "effective C++ statement". All of those well defined in his textbook I bet.
  - Anderkent 14y ago
    numbers suggest around 2% accuracy (7.1) It's more likely he just rounded a number of results and rounded to the first decimal place to display it better, not to suggest some level of accuracy.
- defen 14y ago
  Not counting constructors/destructors toward the total? That's the only thing that immediately comes to mind.
- ScottyE 14y ago
  This is based off general programming knowledge, as I have never used C++, but I think it is referring to a highly-modulated programming style that uses many general functions. I.e., instead of writing a few quick lines of code to perform bisection search in the middle of logic flow, you create a general bisection search function and implement that. This leads to high productivity "a statement per function", and makes code cleaner and easier to update, but can substantially increase overhead costs.
  - 14y ago
psn 14y ago
https://plus.google.com/103382935642834907366/posts/XRekvZgdnBb https://plus.google.com/103382935642834907366/posts/XRekvZgd... is a Chrome developer talking about cache metrics within chrome. He claims the cache is capped at 320MB. Now the graphs in the article never show the cache size hitting 320M, so possibly they are both right. ;) I would prefer it if the article had more information on how to reproduce their tests. For example, they claim a faulty hashmap implementation. This seems like it would be possible to benchmark. Instructions on reproducing the 100ms delay between button click and network traffic would be cool too - as would data on how much worse that makes facebook's latency. Also, is their cache backed by ssds or spinning disk? I'm also impressed that the speed of context switches matters on websites. The jump to claiming that chrome caching is tied to ads is interesting. Perhaps the author could fill in more details.
- hobohacker 14y ago
  I am said Chromium developer. 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/10/11/cache-is-king/, http://www.stevesouders.com/blog/2012/03/22/cache-them-if-you-can/ 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.
xpose2000 14y ago
This is a fantastic blog post, and I am thankful Alex took the time to write about it. There is no question someone over at the Chrome team is starting a conversation about these findings. The best thing about Chrome is that they move fast. So I suppose the first step is to get an official response by someone over there....
dhconnelly 14y ago
For anyone who wants more background on Chrome's multi-process model: - Architecture: http://dev.chromium.org/developers/design-documents/multi-process-architecture http://dev.chromium.org/developers/design-documents/multi-pr... - Models: http://dev.chromium.org/developers/design-documents/process-models http://dev.chromium.org/developers/design-documents/process-... - IPC: http://dev.chromium.org/developers/design-documents/inter-process-communication http://dev.chromium.org/developers/design-documents/inter-pr... - Sandbox: http://dev.chromium.org/developers/design-documents/sandbox http://dev.chromium.org/developers/design-documents/sandbox
- js2 14y ago
  And how it differs from WebKit2 http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2
cooldeal 14y ago
>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 >Some of these issues - such as the "infinite history" or the antiquated style of process isolation - may be driven by Google's business needs, rather than the well-being of the Internet as a whole. How does caching the files indefinitely lead to better ad targeting? Keeping the history, perhaps, but I don't believe Chrome's web history is used to target ads when they have a lot of other ways of doing it, like Google cookies from people logging into Gmail at home and work, third party sites using Ad Words or Google+ etc. etc.
- Filligree 14y ago
  > How does caching the files indefinitely lead to better ad targeting? It doesn't, of course. That's pure FUD; Chrome doesn't contribute to ad-serving in any form other browsers don't. The differences between Chrome and Chromium aren't that large, people would notice.
  - Cthulhu_ 14y ago
    >> How does caching the files indefinitely lead to better ad targeting? >It doesn't, of course. That's pure FUD; Chrome doesn't contribute to ad-serving in any form other browsers don't. Actually, I'd argue that caching files (indefinitely or otherwise) speeds up the internet for the user; higher speed = more pageviews = more ad impressions and potential ad clicks. Google's quest for internet speed is a win-win-win win for us since we get faster internet, win for them since they get more ad impressions / revenue, another win for them for gaining goodwill and a positive reputation.
    - ybaumes 14y ago
      I would go further with your argument (which is perfectly valid for me) for the sake of completeness: it helps them to have a foot in web standardization and, more importantly, to offer a viable alternative solution, fully integrated and "in control". Secured. I don't think it is only a matter of "speed". :-) Before Chrome they were to the "mercy" of the leader in the market place: IE - with its OS companion MS-Windows, the first "barrier" to the the web. Which is the main playground of Google. IE was not really moving the web forward, and known for a lot of issues. I remember people reluctant to use they credit card on the web, because of their unconscious feelings of MS-Windows/MS-IE insecurities. Stuff evolved A LOT from there. Microsoft IE is now much more respectful of the w3c standard AFAIK, more stable, etc. And as you see, from that stability emerged a lot of business. I could not envisaged so much possibilities if the status-quo was still holding today as in 1998. I would make a bold statement, saying that thanks to FireFox, Chrome, Hackers, we are now seeing all those startups... It was a very important challenge for Google (and it is not finished) because they have incentive in people using the "open" web more and more, as you told. The more user on the internet, the more time they spend on it, as you said, the more they watch ads/spend money/consume. And I still know people frightened by this "Tool" that they don't understand. Viruses, Credit card number steal, etc. "Who are those guys, the Anonymous hackers?" I was asked not a long time ago. I was visiting friends owning a PS3 when the PS3 network have been closed down because of act of pirating, totally chocked by its useless video games. Etc, etc. Long list of example. Google understood early that it was in their interest to work on that matter. Those topics will take more and more place in news in the near future, I guess. Google won't be able to sort everything out of course. But they were needing to push further the control of their own fortune. Chrome was a step forward going into the action. They are still working on that full "Vertical" offer. Chrome was just ONE part of the full scheme. They've released Android, now they are releasing Google Pixel. Tomorrow, Google glass. That must be exciting times at Google because the work of so much year is taking forms, and I guess it will translates in even a better future. At least they are showing to me that they perfectly envision from a long time ago which the treats are and the challenges for their business. And how to tackle them. Facebook, native guis, any other kind of "closed" web (as opposed to open web) are another kind of threats, but that is another story, I guess... :-) .
waltz 14y ago
Chrome should get rid of that hideous download bar
chadaustin 14y ago
Having tested the interactivity of various WebGL applications on low-to-medium-end graphics cards, I will say that Chrome's does have significantly higher latency than Firefox. Try this demo: http://n3emscripten.appspot.com/instancing.html http://n3emscripten.appspot.com/instancing.html Crank the number of instances up until the frame rate drops (on my Intel HD Graphics 4000 it's about 20,000) and then drag your mouse. Notice that the drag latency is significantly worse in Chrome than Firefox.
- fastest963 14y ago
  I can get up to 51k before I start to notice a drop in Chrome (M27) and in Firefox (R19) I can only get to about 27k. So it might just be that Chrome isn't optimized for your Intel graphics and is better with dedicated cards?
stanleydrew 14y ago
"... and perhaps [Chrome's aggressive caching] simply is driven by the desire to collect more information to provide you with more relevant ads." The whole article loses credibility with me because of that one statement. Surely this guy knows that a local DNS or document or image cache is not being used to provide the Google mothership with more data to improve Adwords performance, right?
linuxhansl 14y ago
I have done my own tests a while ago (with Firefox and Chromium) and have concluded that for the sites that I frequent Firefox performs much better and uses less RAM. Every now and then I repeat that experiment... So far always with the same outcome. The notion that Chrome is faster is mostly measured by benchmarks; for my browsing behavior that does not translate to real real life performance.
- logn 14y ago
  I had the same experience. For a while when I was using a slow internet connection, I noticed speed differences a lot. For a few sessions I would try loading each page on Firefox, Chrome, and Safari, and Firefox was clearly the fastest. This is another reason why we should be wary of everything moving to WebKit. If one day it's just too slow, we're not left with easy options to move away from it.
ChuckMcM 14y ago
There was in interesting "Ah ha" moment in the development of the Xerox Star system when they figured out all the layers of abstraction meant that each character placed was taking a lot of subroutine calls. Flattening the architecture resulted in a 10x improvement in performance. It was an amazing result.
ComputerGuru 14y ago
I don't understand why the author comes across as having a serious axe to grind. What is aptiverse's horse in the race? Also this: 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. I don't know about him, but I LOVE the fact that Chrome will show me if a link in purple or whatever if I visited it 2 years ago. Completely, totally, absolutely love. Other browsers can be (the last time I checked) configured to behave similarly. When you browse hundreds of web pages a day, catalog only a few of them, and then research a topic you once looked up over a year ago again, it helps to know which pages you've seen and which you haven't.
- vor_ 14y ago
  But the drawback, according to the article, is an increasingly expensive impact on cache lookup over time.
  - ComputerGuru 14y ago
    As the author notes, that's mainly due to the (according to him, but also the only explanation I can think of) lookup table implementation. Something like this should be done in a hash table for constant lookup regardless of the number of entries (as entries are not being added "in real time" non-stop, the cost of bucket resizing shouldn't be too great) or with a trie for the best storage properties for many URLs for the same domain (the case author notes). If done right (correct hashing algorithm, good implementation, decent collision handling for the hash table; or any decently-performing in terms of space/time for the trie) this shouldn't be a problem.
    - josephpmay 14y ago
      Thank you so much on for this comment. I'm currently teaching a lesson on hash tables and this happens to be a great example of their real-world applications and implications.
    - 14y ago
damian2000 14y ago
I started using Chrome in late 2010 and used it continuously until about 3 months ago. It started suffering the problem of tabs just freezing about every few minutes of browsing. This behaviour started happening around the same time on two different machines - one quad core desktop, another lenovo laptop. Since then I've gone back to FireFox, but this article is making me think I may just need to do a fresh install of Chrome.
STRML 14y ago
When it comes to browser benchmarks, there is a lot of emphasis on JS performance, page load time, and memory consumption. But one area where I've seen Chrome absolute fall apart is scrolling performance. Safari regularly gives me 3-5x the frame rate when scrolling, to the point where some websites are nearly unusable on Chrome (say, Reddit with RES) but are butter-smooth on Safari.
dbloom 14y ago
"This is because the synchronization needs to occur over a low-throughput, queue-based IPC subsystem, accompanied by resource-intensive and unpredictably timed context switches mediated by the operating system. To understant [sic] the scale of this effect, we looked at the latency of synchronous, cross-document DOM writes and window.postMessage() roundtrips." Web pages running in different Chrome renderer processes can only communicate using postMessage. WebKit's design makes it practically impossible to access DOM or JS objects across different processes or threads (the only browser that can do this as IE -- top level browsing contexts have run in different threads in IE since the beginning). You can test this hypothesis by creating two same-origin documents in different processes. In the first window, do window.name="foo"; then in the other, do window.open("javascript:;", "foo").document.documentElement.innerHTML="hello"; this will work in every browser except Chrome. Chrome actually provides a way for web developers to explicitly allow a window.open invocation to create a new renderer process (see http://code.google.com/p/chromium/issues/detail?id=153363 http://code.google.com/p/chromium/issues/detail?id=153363 ). This way, the author can allow Chrome to use a new process if they don't need access to the popup beyond postMessage. So, I have no idea where that peak 800 millisecond DOM access latency came from, but it's not from IPC across renderer processes. I'd love to see the benchmark that was used to get that number.
- taeric 14y ago
  My reading has notoriously sucked lately, but it reads like you are strengthening the blog's point. Is that right?
  - dbloom 14y ago
    The circumstance I described that Chrome doesn't support is very rare in real-world web pages. It's pretty unusual to use window.open to get a JS reference to an existing window, and not supporting that makes Chrome's renderer process model much much simpler. So, it's a reasonable trade-off. TL;DR: Chrome does a good thing. This blog post is written by someone who is not well informed.
    - fastest963 14y ago
ww520 14y ago
While we are at the Chrome performance problems, I have encountered one recently when running Javascript code in Chrome. I have job progress data shipped back from the server to the browser asynchronously, which drives the progress bar and the data are concatenated together for display. Chrome simply can't handle long string of concatenation. It just hangs. Other browsers have no problem.
deleted 14y ago
[deleted]
benologist 14y ago
That's interesting that Chrome's caching is so broken, I wasn't aware it actually existed at all because I use the real internet that is not next door the googleplex and every time I hit the back button I enjoy a 1 - 5 second break waiting for the page to be completely reloaded.
ybaumes 14y ago
I am just wondering here: two blog post from a startup in "stealth" mode. One about CSS "advanced" tricks. The other one about criticizing Chrome browser. Are those guys about to release a competing Web-Browser? :P Too less cues to know, but still the question popped up in my mind. It would explain the criticizing tone of the article. Don't make me tell what I didn't tell: they could be proven right or wrong, it is not my point. I don't want to follow the debate about Chrome performance here. But what I suggest is: unknowing the real goals of Aptiverse's business and their interests I would backup a little bit and try to look at the big picture. And avoid religious Emacs/VI war. But well then, I am trying to make bold bet anyway. They could be about to release a new ground-breaking web-browser in the near future, make everyone switch and fix the issues they announced in their blog post. Don't know what future is made of! :-)
martinced 14y ago
I regularly delete Chrome's cache because I did somehow "discover" that behavior intuitively a long time ago. That said, it's totally silly to criticize security measures for slowing down a bit page rendering / navigation. I'm taking a 50% slower Internet today if, in exchange, it's 100% secure. I know it's not doable and won't happen any time soon. But those willing to sacrifice security in the name of perfs should be shot to dead.

318 points by mrjbq7 14y ago

Revisor 14y ago

Two days later and this article doesn't exist. So much for link rot.

makimoto 14y ago

Did anyone save this offline? it's no longer available

33a 14y ago

The only real wtf here is the history issue. The rest of the stuff -- especially the "antiquated" process isolation -- seem like reasonable trade offs. Switching to a better hash implementation should solve 90% of the performance problems.

comex 14y ago

The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to do anything at all. I don't know any other projects that do what NaCl does, so regardless of whether Google should switch to pure NaCl for sandboxing, if they did, it would be innovation, not scrapping an antiquated technology. As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.

stcredzero 14y ago
> The claim that process isolation is "antiquated" is absurd Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.
- loeg 14y ago
  I don't know about these claims — just because most OS research is now 20+ years old doesn't mean that a result, process isolation, is antiquated. You likely use a very modern operating system with process time-sharing (1964) using virtual memory (1950s/1960s) and so many other results of OS research from 30+ years ago… This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.
zobzu 14y ago
Yup, I think some people don't realize why processes exist and what they're here for. It just looks like a concept that we've been using for a long time so, "it must be too old and be replaced", without understanding _how_ it works and _why_ it's there.
- gtirloni 14y ago
  As everything in IT.
cpeterso 14y ago
Firefox uses a sandbox process for plugins like Flash. Mozilla implemented per-tab processes, a project called Electrolysis, but it would break many popular add-ons. Firefox OS is able to use process isolation, through, because it doesn't need to support legacy add-ons.
- comex 14y ago
  Really? I haven't heard a single thing about Electrolysis in a long time, except I remember reading somewhere recently that it was abandoned. I'm happy to hear that Firefox OS is using it; still, keeping legacy add-ons working seems like a bad reason to stop pursuing such an important security feature on the desktop.

barista 14y ago

A quote worth noting from the article: "Some of these issues - such as the "infinite history" or the antiquated style of process isolation - may be driven by Google's business needs, rather than the well-being of the Internet as a whole. Until this situation changes, our only recourse is to test a lot - and always have a backup plan."

lenazegher 14y ago
This glosses over how anti-user infinite history is. The problem of the ever-expanding cache is annoying but easy to deal with - Ctrl+Shift+Del, select only "cache", then "obliterate since the beginning of time". But if you follow this procedure with your browsing history, your (or at least, my) browsing experience is significantly degraded because all your URL autocompletes are gone, at least until you re-visit all your regular sites. You can tell chrome to delete, say, just your browsing history from the last week, but that doesn't help you when what you want to do is delete all browsing history except that from the last week (to preserve your autocompletes). It's a real PITA.
- wonderzombie 14y ago
  https://news.ycombinator.com/item?id=5282234 https://news.ycombinator.com/item?id=5282234 The cache is not infinite.
cpleppert 14y ago
In what possible world could process isolation be driven by business needs? For that matter to describe it as being 'antiquated' is rather bizarre. Every modern browser is moving in that direction including IE10 for security and performance reasons. For that matter, I have no idea what 'infinite history' means, every browser records history and I have no clue how that could possibly impact performance in the slightest.

aristidb 14y ago

I don't buy the claim that process isolation is superseded by NaCl-style validation.

cpleppert 14y ago
I agree... You can only validate what is presented to you; a hacker won't kindly hand you a piece of code to run after exploited a hole and ask you to verify it. It also rather circuitous, browsers already verify what they are executing.

zobzu 14y ago

So uhm, it seems like firefox is faster than chrome after a week of use :p

ceautery 14y ago
Unless you clear your cache, in which case, in addition to being more secure, Chrome is faster.
- mbetter 14y ago
  Except when you are typing a URL.
  - spoiler 14y ago
    Are you talking about performance issues as in visual lag, or performance issues as in "the list is empty for a while", because I experience neither, but a friend of mine had issues where no suggestions would show up for a while, but he relied upon them for some reason, and it annoyed him.
    - mbetter 14y ago
      I'm talking about a cache clear blowing out autocomplete history.
- LeonidasXIV 14y ago
  Why is Chrome more secure? Did I miss a memo? I was under the impression that Firefox security issues are fixed in a pretty decent manner.
  - mtgx 14y ago
    Because of tab sandboxing.
  - spoiler 14y ago
    To be honest I just trust chromium (and chrome) more. I am not even a sure why. Sort of gives me a sense of reliability, security and stability. I had performance issues with Firefox in the past, though, but I doubt that's it. I guess what make a me feel all tingly inside is the GUI, which I love.

polskibus 14y ago

Opinion on process isolation is the most controversial statement in the article, but the other claims are more interesting and easier to verify. If the findings are confirmed by others, it will hopefully drive webkit/chromium ecosystem towards improvement.

veb 14y ago

This is probably off-topic, but I've started using Safari religiously now. When Chrome first came out, it was barebones, fast and did the job. This is what Safari currently feels like, so I'm using it. Fast, stable, and does the job. Now Chrome feels like it's just another bloated browser. Which is slow, and hogs my computer. </opinion>

webwanderings 14y ago
As I recall, they stopped updating the browser for Windows after certain version. So comparing Safari to Chrome seems misplaced in this context.
- scholia 14y ago
  If he uses Safari, I'd assume he has a Mac....
  - spoiler 14y ago
    Well, I used Safari before Chrome, came out... Firefox was dreadfully slow on my old computer. :(
    - scholia 14y ago
      Well, I said "uses" not "used" ;-)
stock_toaster 14y ago
I admit to liking Safari, and enjoy the seamless experience (on a mac), but I am a bit hesitant to switch completely given some of the things Safari apparently lacks in the realm of security. As an example, I don't believe Safari currently supports HSTS or cert pinning. Both Chrome and Firefox do.
diggan 14y ago
What in Chrome feels like bloat? If you don't install any extensions but adblock plus, Chrome feels kind of minimalistic. The only problem I have with Chrome is that I need to clear cache and history quite often but my computer sucks...

jgrahamc 14y ago

This philosophy is embraced by the developers working on WebKit: in fact, the code responsible for rendering a typical web page averages just 2.1 effective C++ statements per function in WebKit, compared to 6.3 for Firefox - and an estimated count of 7.1 for Internet Explorer. What is an "effective C++ statement"? That's a really odd measure and I can't get my head around it.

fijal 14y ago
It's marketing bullshit. He probably wrote a statement in C++ and measured the time it takes to execute, I have no idea (also impossible to know what sort of statement). numbers suggest around 2% accuracy (7.1), that's pretty impressive given that we measure "code responsible for rendering a typical web page" per "function" over "effective C++ statement". All of those well defined in his textbook I bet.
- Anderkent 14y ago
  numbers suggest around 2% accuracy (7.1) It's more likely he just rounded a number of results and rounded to the first decimal place to display it better, not to suggest some level of accuracy.
defen 14y ago
Not counting constructors/destructors toward the total? That's the only thing that immediately comes to mind.
ScottyE 14y ago
This is based off general programming knowledge, as I have never used C++, but I think it is referring to a highly-modulated programming style that uses many general functions. I.e., instead of writing a few quick lines of code to perform bisection search in the middle of logic flow, you create a general bisection search function and implement that. This leads to high productivity "a statement per function", and makes code cleaner and easier to update, but can substantially increase overhead costs.
- 14y ago

psn 14y ago

https://plus.google.com/103382935642834907366/posts/XRekvZgdnBb https://plus.google.com/103382935642834907366/posts/XRekvZgd... is a Chrome developer talking about cache metrics within chrome. He claims the cache is capped at 320MB. Now the graphs in the article never show the cache size hitting 320M, so possibly they are both right. ;) I would prefer it if the article had more information on how to reproduce their tests. For example, they claim a faulty hashmap implementation. This seems like it would be possible to benchmark. Instructions on reproducing the 100ms delay between button click and network traffic would be cool too - as would data on how much worse that makes facebook's latency. Also, is their cache backed by ssds or spinning disk? I'm also impressed that the speed of context switches matters on websites. The jump to claiming that chrome caching is tied to ads is interesting. Perhaps the author could fill in more details.

hobohacker 14y ago
I am said Chromium developer. 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/10/11/cache-is-king/, http://www.stevesouders.com/blog/2012/03/22/cache-them-if-you-can/ 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.

xpose2000 14y ago

This is a fantastic blog post, and I am thankful Alex took the time to write about it. There is no question someone over at the Chrome team is starting a conversation about these findings. The best thing about Chrome is that they move fast. So I suppose the first step is to get an official response by someone over there....

dhconnelly 14y ago

For anyone who wants more background on Chrome's multi-process model: - Architecture: http://dev.chromium.org/developers/design-documents/multi-process-architecture http://dev.chromium.org/developers/design-documents/multi-pr... - Models: http://dev.chromium.org/developers/design-documents/process-models http://dev.chromium.org/developers/design-documents/process-... - IPC: http://dev.chromium.org/developers/design-documents/inter-process-communication http://dev.chromium.org/developers/design-documents/inter-pr... - Sandbox: http://dev.chromium.org/developers/design-documents/sandbox http://dev.chromium.org/developers/design-documents/sandbox

js2 14y ago
And how it differs from WebKit2 http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2

cooldeal 14y ago

>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 >Some of these issues - such as the "infinite history" or the antiquated style of process isolation - may be driven by Google's business needs, rather than the well-being of the Internet as a whole. How does caching the files indefinitely lead to better ad targeting? Keeping the history, perhaps, but I don't believe Chrome's web history is used to target ads when they have a lot of other ways of doing it, like Google cookies from people logging into Gmail at home and work, third party sites using Ad Words or Google+ etc. etc.

Filligree 14y ago
> How does caching the files indefinitely lead to better ad targeting? It doesn't, of course. That's pure FUD; Chrome doesn't contribute to ad-serving in any form other browsers don't. The differences between Chrome and Chromium aren't that large, people would notice.
- Cthulhu_ 14y ago
  >> How does caching the files indefinitely lead to better ad targeting? >It doesn't, of course. That's pure FUD; Chrome doesn't contribute to ad-serving in any form other browsers don't. Actually, I'd argue that caching files (indefinitely or otherwise) speeds up the internet for the user; higher speed = more pageviews = more ad impressions and potential ad clicks. Google's quest for internet speed is a win-win-win win for us since we get faster internet, win for them since they get more ad impressions / revenue, another win for them for gaining goodwill and a positive reputation.
  - ybaumes 14y ago
    I would go further with your argument (which is perfectly valid for me) for the sake of completeness: it helps them to have a foot in web standardization and, more importantly, to offer a viable alternative solution, fully integrated and "in control". Secured. I don't think it is only a matter of "speed". :-) Before Chrome they were to the "mercy" of the leader in the market place: IE - with its OS companion MS-Windows, the first "barrier" to the the web. Which is the main playground of Google. IE was not really moving the web forward, and known for a lot of issues. I remember people reluctant to use they credit card on the web, because of their unconscious feelings of MS-Windows/MS-IE insecurities. Stuff evolved A LOT from there. Microsoft IE is now much more respectful of the w3c standard AFAIK, more stable, etc. And as you see, from that stability emerged a lot of business. I could not envisaged so much possibilities if the status-quo was still holding today as in 1998. I would make a bold statement, saying that thanks to FireFox, Chrome, Hackers, we are now seeing all those startups... It was a very important challenge for Google (and it is not finished) because they have incentive in people using the "open" web more and more, as you told. The more user on the internet, the more time they spend on it, as you said, the more they watch ads/spend money/consume. And I still know people frightened by this "Tool" that they don't understand. Viruses, Credit card number steal, etc. "Who are those guys, the Anonymous hackers?" I was asked not a long time ago. I was visiting friends owning a PS3 when the PS3 network have been closed down because of act of pirating, totally chocked by its useless video games. Etc, etc. Long list of example. Google understood early that it was in their interest to work on that matter. Those topics will take more and more place in news in the near future, I guess. Google won't be able to sort everything out of course. But they were needing to push further the control of their own fortune. Chrome was a step forward going into the action. They are still working on that full "Vertical" offer. Chrome was just ONE part of the full scheme. They've released Android, now they are releasing Google Pixel. Tomorrow, Google glass. That must be exciting times at Google because the work of so much year is taking forms, and I guess it will translates in even a better future. At least they are showing to me that they perfectly envision from a long time ago which the treats are and the challenges for their business. And how to tackle them. Facebook, native guis, any other kind of "closed" web (as opposed to open web) are another kind of threats, but that is another story, I guess... :-) .

waltz 14y ago

Chrome should get rid of that hideous download bar

chadaustin 14y ago

Having tested the interactivity of various WebGL applications on low-to-medium-end graphics cards, I will say that Chrome's does have significantly higher latency than Firefox. Try this demo: http://n3emscripten.appspot.com/instancing.html http://n3emscripten.appspot.com/instancing.html Crank the number of instances up until the frame rate drops (on my Intel HD Graphics 4000 it's about 20,000) and then drag your mouse. Notice that the drag latency is significantly worse in Chrome than Firefox.

fastest963 14y ago
I can get up to 51k before I start to notice a drop in Chrome (M27) and in Firefox (R19) I can only get to about 27k. So it might just be that Chrome isn't optimized for your Intel graphics and is better with dedicated cards?

stanleydrew 14y ago

"... and perhaps [Chrome's aggressive caching] simply is driven by the desire to collect more information to provide you with more relevant ads." The whole article loses credibility with me because of that one statement. Surely this guy knows that a local DNS or document or image cache is not being used to provide the Google mothership with more data to improve Adwords performance, right?

linuxhansl 14y ago

I have done my own tests a while ago (with Firefox and Chromium) and have concluded that for the sites that I frequent Firefox performs much better and uses less RAM. Every now and then I repeat that experiment... So far always with the same outcome. The notion that Chrome is faster is mostly measured by benchmarks; for my browsing behavior that does not translate to real real life performance.

logn 14y ago
I had the same experience. For a while when I was using a slow internet connection, I noticed speed differences a lot. For a few sessions I would try loading each page on Firefox, Chrome, and Safari, and Firefox was clearly the fastest. This is another reason why we should be wary of everything moving to WebKit. If one day it's just too slow, we're not left with easy options to move away from it.

ChuckMcM 14y ago

There was in interesting "Ah ha" moment in the development of the Xerox Star system when they figured out all the layers of abstraction meant that each character placed was taking a lot of subroutine calls. Flattening the architecture resulted in a 10x improvement in performance. It was an amazing result.

ComputerGuru 14y ago

I don't understand why the author comes across as having a serious axe to grind. What is aptiverse's horse in the race? Also this: 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. I don't know about him, but I LOVE the fact that Chrome will show me if a link in purple or whatever if I visited it 2 years ago. Completely, totally, absolutely love. Other browsers can be (the last time I checked) configured to behave similarly. When you browse hundreds of web pages a day, catalog only a few of them, and then research a topic you once looked up over a year ago again, it helps to know which pages you've seen and which you haven't.

vor_ 14y ago
But the drawback, according to the article, is an increasingly expensive impact on cache lookup over time.
- ComputerGuru 14y ago
  As the author notes, that's mainly due to the (according to him, but also the only explanation I can think of) lookup table implementation. Something like this should be done in a hash table for constant lookup regardless of the number of entries (as entries are not being added "in real time" non-stop, the cost of bucket resizing shouldn't be too great) or with a trie for the best storage properties for many URLs for the same domain (the case author notes). If done right (correct hashing algorithm, good implementation, decent collision handling for the hash table; or any decently-performing in terms of space/time for the trie) this shouldn't be a problem.
  - josephpmay 14y ago
    Thank you so much on for this comment. I'm currently teaching a lesson on hash tables and this happens to be a great example of their real-world applications and implications.
  - 14y ago

damian2000 14y ago

I started using Chrome in late 2010 and used it continuously until about 3 months ago. It started suffering the problem of tabs just freezing about every few minutes of browsing. This behaviour started happening around the same time on two different machines - one quad core desktop, another lenovo laptop. Since then I've gone back to FireFox, but this article is making me think I may just need to do a fresh install of Chrome.

STRML 14y ago

When it comes to browser benchmarks, there is a lot of emphasis on JS performance, page load time, and memory consumption. But one area where I've seen Chrome absolute fall apart is scrolling performance. Safari regularly gives me 3-5x the frame rate when scrolling, to the point where some websites are nearly unusable on Chrome (say, Reddit with RES) but are butter-smooth on Safari.

dbloom 14y ago

"This is because the synchronization needs to occur over a low-throughput, queue-based IPC subsystem, accompanied by resource-intensive and unpredictably timed context switches mediated by the operating system. To understant [sic] the scale of this effect, we looked at the latency of synchronous, cross-document DOM writes and window.postMessage() roundtrips." Web pages running in different Chrome renderer processes can only communicate using postMessage. WebKit's design makes it practically impossible to access DOM or JS objects across different processes or threads (the only browser that can do this as IE -- top level browsing contexts have run in different threads in IE since the beginning). You can test this hypothesis by creating two same-origin documents in different processes. In the first window, do window.name="foo"; then in the other, do window.open("javascript:;", "foo").document.documentElement.innerHTML="hello"; this will work in every browser except Chrome. Chrome actually provides a way for web developers to explicitly allow a window.open invocation to create a new renderer process (see http://code.google.com/p/chromium/issues/detail?id=153363 http://code.google.com/p/chromium/issues/detail?id=153363 ). This way, the author can allow Chrome to use a new process if they don't need access to the popup beyond postMessage. So, I have no idea where that peak 800 millisecond DOM access latency came from, but it's not from IPC across renderer processes. I'd love to see the benchmark that was used to get that number.

taeric 14y ago
My reading has notoriously sucked lately, but it reads like you are strengthening the blog's point. Is that right?
- dbloom 14y ago
  The circumstance I described that Chrome doesn't support is very rare in real-world web pages. It's pretty unusual to use window.open to get a JS reference to an existing window, and not supporting that makes Chrome's renderer process model much much simpler. So, it's a reasonable trade-off. TL;DR: Chrome does a good thing. This blog post is written by someone who is not well informed.
  - fastest963 14y ago

ww520 14y ago

While we are at the Chrome performance problems, I have encountered one recently when running Javascript code in Chrome. I have job progress data shipped back from the server to the browser asynchronously, which drives the progress bar and the data are concatenated together for display. Chrome simply can't handle long string of concatenation. It just hangs. Other browsers have no problem.

deleted 14y ago

[deleted]

benologist 14y ago

That's interesting that Chrome's caching is so broken, I wasn't aware it actually existed at all because I use the real internet that is not next door the googleplex and every time I hit the back button I enjoy a 1 - 5 second break waiting for the page to be completely reloaded.

ybaumes 14y ago

I am just wondering here: two blog post from a startup in "stealth" mode. One about CSS "advanced" tricks. The other one about criticizing Chrome browser. Are those guys about to release a competing Web-Browser? :P Too less cues to know, but still the question popped up in my mind. It would explain the criticizing tone of the article. Don't make me tell what I didn't tell: they could be proven right or wrong, it is not my point. I don't want to follow the debate about Chrome performance here. But what I suggest is: unknowing the real goals of Aptiverse's business and their interests I would backup a little bit and try to look at the big picture. And avoid religious Emacs/VI war. But well then, I am trying to make bold bet anyway. They could be about to release a new ground-breaking web-browser in the near future, make everyone switch and fix the issues they announced in their blog post. Don't know what future is made of! :-)

martinced 14y ago

I regularly delete Chrome's cache because I did somehow "discover" that behavior intuitively a long time ago. That said, it's totally silly to criticize security measures for slowing down a bit page rendering / navigation. I'm taking a 50% slower Internet today if, in exchange, it's 100% secure. I know it's not doable and won't happen any time soon. But those willing to sacrifice security in the name of perfs should be shot to dead.