Now Chrome feels like it's just another bloated browser. Which is slow, and hogs my computer. </opinion>
The only problem I have with Chrome is that I need to clear cache and history quite often but my computer sucks...
You could try Firefox again, but reset your profile first: https://blog.mozilla.org/nnethercote/2013/02/22/reset-firefo....
The hardest part is finding the downloads, since they go to great lengths to prevent anyone from easily obtaining a compiled binary.
Why 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.
1. Googled "Download Chromium"
2. Clicked on http://download-chromium.appspot.com/
3. Unzip and Install.
As an example, I don't believe Safari currently supports HSTS or cert pinning. Both Chrome and Firefox do.
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.
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.
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.
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.
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.
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.
"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.
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 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.
>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.
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.
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.
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.
- 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
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.
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.
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?
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! :-)
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....
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.
