A closer look at the performance of Google Chrome

http://aptiverse.com/blog/closer_look_at_chrome/

by mrjbq7 • 13 years ago

318 163 13 years ago

comex3• 13 years 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• 13 years 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• 13 years 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.

zobzu2• 13 years 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• 13 years ago

As everything in IT.

cpeterso• 13 years 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.

comex3• 13 years 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.

mistercow3• 13 years ago

The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.

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.

azakai2• 13 years ago

> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.

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.

comex3• 13 years ago

Another quote is

"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.

dxdt• 13 years ago

There's no way that "resource-intensive and unpredictably timed context switches" account for 100-200ms on modern hardware. With modern multi-core/cpu boxes I think a typical time for a context switch is on the order of 10 microseconds, and that doesn't take into account in things like CPU affinity. (It's still going to depend on a lot on OS and hardware. For example: new i7 vs old core architecture)

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.

barista• 13 years 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• 13 years 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• 13 years ago

https://news.ycombinator.com/item?id=5282234

The cache is not infinite.

cpleppert2• 13 years 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• 13 years ago

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

cpleppert2• 13 years 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.

zobzu2• 13 years ago

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

ceautery• 13 years ago

Unless you clear your cache, in which case, in addition to being more secure, Chrome is faster.

mbetter2• 13 years ago

Except when you are typing a URL.

LeonidasXIV2• 13 years 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.

polskibus• 13 years 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• 13 years 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• 13 years ago

As I recall, they stopped updating the browser for Windows after certain version. So comparing Safari to Chrome seems misplaced in this context.

scholia2• 13 years ago

If he uses Safari, I'd assume he has a Mac....

stock_toaster• 13 years 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.

diggan2• 13 years 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...

k3n8• 13 years ago

They've gone overboard with their value-adds, and there's a non-trivial amount of features that are not required for simple web surfing: sync, apps (& background apps), cloud print, themes, phishing/malware detection, omnibox stuff, etc.

jv-2• 13 years ago

IMHO, cloud print, the webui reimplementation of gui system toolkits (like the print preview dialog). There are some new features that make me a bit worried with the direction chrome is taking: the new NTP with a search box duplicating functionality already in the omnibar; the chrome app launcher (I want a browser, not a whole OS).

justincormack• 13 years ago

Adblock plus seems to slow it down quite a bit in some situations (loading a lot of tabs at once).

k3n8• 13 years ago

Perhaps Chromium proper would be a good fit for you; it's got the polish of Chrome UI but lacks all of that crap that Google has started bundling with Chrome (sync, etc.).

The hardest part is finding the downloads, since they go to great lengths to prevent anyone from easily obtaining a compiled binary.

mayanksinghal4• 13 years ago

> 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.

magicalist2• 13 years ago

Chromium includes sync. Basically the biggest parts you'll be missing are a pdf reader and flash. pdf.js has a chromium extension to make it easy to use there (though depending on the document, it won't necessarily feel faster and more minimal), but if you need flash for something, Chrome is one of the better ways to keep it updated these days. You can always run Chromium and open up Chrome for Flash, though.

night815• 13 years ago

http://www.chromium.org/getting-involved/download-chromium

keeperofdakeys2• 13 years ago

The stuff that is included with Chrome shouldn't have any impact on performance, the webkit and v8 engines are the same as that of Chromium. For Google, they do all their development on Chromium (which is an open source project), then apply a few patches and a new logo on top to get Chrome. It isn't some great conspiracy that they don't distribute Chromium binaries, it simply isn't their end product.

dfc• 13 years ago

Pretty easy:

    apt-get install chromium

mistercow3• 13 years ago

>all of that crap that Google has started bundling with Chrome (sync, etc.).

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.

wil421• 13 years ago

The pinch and zoom feels much smoother on Safari, it's especially helpful on my laptop when viewing from a distance.

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.

jcromartie• 13 years ago

But then you're just in Google's garden...

andrewparker• 13 years ago

Uninstall any extensions you have running in Chrome to get it feeling fresh again. In my personal experience (strictly subjective, not benchmarked), a clean chrome install runs faster than a clean Safari install.

nnethercote• 13 years ago

Sounds like profile problems to me.

You could try Firefox again, but reset your profile first: https://blog.mozilla.org/nnethercote/2013/02/22/reset-firefo....

habosa• 13 years ago

That's exactly where I am. Chrome got to the point where it was using 2GB+ of memory. Safari uses a lot too, but consistently less than 1/2 of what Chrome would use and seems not to leak as much over time. It also boots MUCH, MUCH faster.

jgrahamc• 13 years 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• 13 years 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• 13 years 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• 13 years ago

Not counting constructors/destructors toward the total? That's the only thing that immediately comes to mind.

ScottyE• 13 years 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.

emn136• 13 years ago

No, C++ is particularly well suited to that since it's possible to implement those with zero (and in practice less than zero) overhead. The problem is overridable functions; i.e. not generic implementations that work on various structures by compiler specialization, but methods on classes whose implementation varies at runtime by dynamic dispatch. E.g. a getLayoutWidth method with a different implementation for blocks and inline runs, and where it's possible to call the implementation without knowing at compile time which it is.

Those cost performance.

duaneb• 13 years ago

I don't know, but I suspect it's a completely meaningless unit.

taf2• 13 years ago

Last I heard IE was closed source ... I'd love to know how he got his hands on the IE code base to make that measurement... All his posturing about - design decisions being a business need of google make me wonder whether this was a M$ sponsored article...

Someone• 13 years ago

They say 'estimated'. A way to do that is to look at the disassembly of IE code, assuming an on average constant number of assembly instructions per C statement. I don't think that is a bad assumption, but it does ignore potential differences between compilers.

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.

jamesaguilar• 13 years ago

Well you could instrument the source code and measure the number of calls, and compare that to the rough number of non-call ops per function. Not a perfect metric but it's something. His claims do seem far fetched though.

recoiledsnake• 13 years ago

>M$

Please, this is not Slashdot or /r/linux.

http://www.penny-arcade.com/comic/2002/07/22

jrogers65• 13 years ago

They mean that each function does relatively little work, so to render a given web page, the number of function calls (and therefore vtable lookups) is higher than in other browsers. This translates to more overheads and slower execution.

jv-2• 13 years ago

Doesn't the compiler inline this kind of functions?

psn• 13 years ago

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.

hobohacker2• 13 years 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/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.

sdepablos• 13 years ago

I don't know when you changed the behavior, but until a few months ago the cache was infinite. I close friend was unable to use Chrome because it took minutes - yes, minutes - to boot until we found is was a problem related with the huge cache it was maintaining.

slacka2• 13 years ago

To set the cache to only 100MB, you can always use the "--disk-cache-size=104857600" flag.

My issue with chrome is that it eats up a lot more RAM than Firefox. When doing research, I often have 30-50 tabs open. With Chrome my system runs out of physical RAM and starts thrashing. With Firefox, the UI becomes unresponsive due to it's single threaded design.

I wish Chrome would start a Memshrink project like Mozilla did or Mozilla would finish with they started with electrolysis.

jfb• 13 years ago

If the hash map in infinite_cache.cc is broken, how about a footnote explaining why? The lack of specificity here was a bad blog smell, in my eyes.

xpose2000• 13 years 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....

33a• 13 years 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.

dhconnelly2• 13 years ago

For anyone who wants more background on Chrome's multi-process model:

- 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

js2• 13 years ago

And how it differs from WebKit2 http://trac.webkit.org/wiki/WebKit2

cooldeal• 13 years 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• 13 years 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_2• 13 years 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.

argsv• 13 years ago

As soon as I read the part where the author is hinting that Chrome uses user's browser history to deliver more relevant ads I thought the author either does not understand how the history feature work or he is being disingenuous. I've been using chrome for nearly 4 years without ever deleting history. The only slow pages that I've experienced are the non-English pages (Arabic in particular). They (non-English pages) are slow specially after an update.

waltz• 13 years ago

Chrome should get rid of that hideous download bar

chadaustin• 13 years 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

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.

fastest9632• 13 years 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?

stanleydrew3• 13 years 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• 13 years 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• 13 years 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• 13 years 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.

ComputerGuru2• 13 years 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_• 13 years ago

But the drawback, according to the article, is an increasingly expensive impact on cache lookup over time.

ComputerGuru2• 13 years 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.

damian2000• 13 years 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• 13 years 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.

dbloom5• 13 years 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 ). 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.

taeric5• 13 years ago

My reading has notoriously sucked lately, but it reads like you are strengthening the blog's point. Is that right?

dbloom5• 13 years 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.

ww520• 13 years 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.

benologist• 13 years 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.

ybaumes2• 13 years 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• 13 years 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.

Revisor• 13 years ago

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

A closer look at the performance of Google Chrome

Related Stories