A closer look at the performance of Google Chrome
aptiverse.com
aptiverse.com
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.
Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.
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.
I think addons are a small part of the picture.
The big deal is there are only so many Firefox developers, and Electrolysis was turning into a real sinkhole of time with no end in sight. There were a lot better ways to make Firefox a better browser in the meantime, and those things are being done.
Firefox on Android used to use Electrolysis until it switched to the current Java front-end. And FirefoxOS is using it for sure: process per app, so that apps can be easily killed in low-memory conditions.
As for "legacy add-ons", that would be "every single add-on". Not to mention that the desktop Firefox UI itself would have to be heavily rewritten as well. The judgement, as mcpherinm says, was that the cost was too high for the possible gains. I agree that process isolation is good for security, but there are various other security mitigation strategies that can be used that had a higher bang for the buck at the time.
In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.
That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
[1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org
It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is.
A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app.
One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
Please do! I would love to read that.
Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
"The mechanism is based on a relatively dated concept, superseded by compile-time code validation techniques such as Google's own Native Client"
so I don't think that's what the article meant.
If there's actually high costs, it shouldn't be due to a "antiquated" multi-process architecture, but other things like marshalling data to and from the JS engine.
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.
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.
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...
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.
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.
Once you take caches into account, hash tables are not ammortized O(1). Having said that, those graphs show delays of well over 100 milliseconds, and that sounds excessive. It's possible the delay is primarily due to a poor implementation and not so much due to inherent limitations.
This is a really tricky optimization because on a positive hit you've introduced more random I/O! After all, you've got the bloom filter and then the hash table lookup. False positives are also bad - so you only save something on true negatives. Is it worth it? Only if you get the tuning just right.
- Architecture: http://dev.chromium.org/developers/design-documents/multi-pr...
- Models: http://dev.chromium.org/developers/design-documents/process-...
- IPC: http://dev.chromium.org/developers/design-documents/inter-pr...
- Sandbox: http://dev.chromium.org/developers/design-documents/sandbox
What is an "effective C++ statement"? That's a really odd measure and I can't get my head around it.
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.
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.
Those cost performance.
Also, IE source likely is available through Microsoft's Shared Source Initiative (http://www.microsoft.com/en-us/sharedsource/default.aspx). After all, Microsoft has vehemently argumented that IE is inseparable from the OS. I think it would require some lenient interpretation of that license to use it for this purpose, though.
Please, this is not Slashdot or /r/linux.
the extensive use of dynamic class inheritance prevents the compiler from efficiently inlining short functions as necessary
MSVC with PGO will do it, by inserting a guard on the vtable pointer and inlining the most common implementation. But you still take the possible cache miss of reading the vtable pointer, of course. And the other commonly used compilers (clang and gcc) don't do anything like this, even with PGO.
Now Chrome feels like it's just another bloated browser. Which is slow, and hogs my computer. </opinion>
As an example, I don't believe Safari currently supports HSTS or cert pinning. Both Chrome and Firefox do.
The only problem I have with Chrome is that I need to clear cache and history quite often but my computer sucks...
I do not see any of the additional stuff that the above poster mentioned. I use exactly one feature in chrome other than just it's web browsing at that is sync. Even then, I haven't interacted with sync since the first time I installed Chrome on my computer.
This is strange since many people say Firefox is bloated but im my opinion it looks about identical to how Chrome looks like, so they seem to define bloat in some other way.
What you would consider bload, I'd call clutter. I de-cluttered my Firefox to this way that I only see the tab-bar, a command-bar and the web page.
Both chrome and firefox have excellent session restore, so even if you need to update (which you usually don't), you won't really notice. Even session cookies are properly restored, as are partially filled forms, though some pages' scripts cause the form restoration to fail.
Toolbars have always been rare, and they certainly are now; it's probably possible to still install a toolbar extension, but I can't remember the last time I did. That may be more a change in typical extension style than in the actual browser, however.
(I use both browsers daily).
I'm sort of just playing devil's advocate here though, since Chrome's "bloat" isn't an issue for me _yet_, though I am weary of it becoming the next Firefox (whose snowballing of features led to an amount of bloat which incidentally caused me to start using Chrome in the first place).
One, two, three... sure, you won't notice a new feature here and there. But, hundreds of features later and the app takes just a little longer to startup, a little longer to update, is slightly less stable than it used to be, has a few more attack vectors for malware, etc. It's more-or-less the principal of the matter, using the right tool for the right job and whatnot; when a web browser starts resembling some mismash conglomeration of functionality which just so happens to touch on web browsing, and all you really need and want is web browsing, then yeah, it's bloated.
I define bloat differently. It needs to a) unnecessarily add complexity to the core functions I personally use, and b) degrades performance. wget has tons of features that I've never used, but I don't consider it bloated. To me, hiding it well does in fact make for a bloat-free application.
Agree with your other points.
But as far as "just give me what I want" I continue to think Chrome does it better.
I think the only strong argument on that side is one you don't make: on first run, Chrome stops and asks you to sign in to your Google account. I do that willingly, because I really like bookmark synchronization. But it's definitely not a "minimal browser" thing and if you're not a Google user it's probably pretty annoying.
The hardest part is finding the downloads, since they go to great lengths to prevent anyone from easily obtaining a compiled binary.
1. Googled "Download Chromium"
2. Clicked on http://download-chromium.appspot.com/
3. Unzip and Install.
PREVIOUS: Yeah I saw that, but that's not an official or sanctioned site or binary, and thus didn't feel comfortable openly suggesting it. There's no way to guarantee that the contents haven't been modified or that they're even kept updated.
> There's no way to guarantee that the contents haven't been modified or that they're even kept updated.
There is no solution to that but to compile things ourselves anyway.
Thanks for the further info though, it's been awhile since I've updated my Chromium.
apt-get install chromiumWhy do people keep bagging on sync? Personally, I'm a fan of not having to reïmport my bookmarks and reënter all of my autosaved passwords every time I reformat or change computers.
Agreed, this was a long time back, so I actually decided to give it another try today, but now it seems to have a problem with 2FA... I gave it both my master and app-specific password, but it consistently comes back saying the app-specific password is wrong. Has anyone else noticed this problem?
It's the same with most RSS readers nowadays... every single app I've tried assumes I have a Google Reader account, and flat out refuses to work without it. Same with Google Talk. All these apps implement rss/xmpp backends anyway, why do they hardcode google into it?
Sorry for the rant, it's just frustrating how (needlessly) difficult it is once you go outside the sanctioned path. Death by a thousand cuts.
Tha being said I'm really tired of being in the "walled garden" I have a Windows desktop and Andriod Tablet that would love to share iCloud tabs and bookmarks. Chrome can do all of that.
You could try Firefox again, but reset your profile first: https://blog.mozilla.org/nnethercote/2013/02/22/reset-firefo....
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?
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.
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! :-)
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.
It also rather circuitous, browsers already verify what they are executing.
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 ). 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.
TL;DR: Chrome does a good thing. This blog post is written by someone who is not well informed.
window.opener = window.open('', clientWindow);
Now, I do think there is room for argument that this is a better way. But you do not seem to be undermining any of the blog's points. Those being that chrome has a slower process to communicate between windows, and that it is the only browser that does this. The frequency with which this is needed was not a point of contention.
My claim is that windows in different processes cannot communicate at all in Chrome. Only same-process windows can communicate -- and that refutes the author's claim that IPC slows down cross-window/frame communication in Chrome.
(In addition, Chrome will sometimes make windows/tabs share a process if there are a lot of tabs open, to save memory. There is a limit to the total number of render processes that Chrome will have.)
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....
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.
>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.
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.
>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.
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... :-) .
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.
The cache is not infinite.
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.
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.