Subsequent to some performance issues with a few Backbone apps, I spent some time digging further into Google Chrome’s timeline panel, and specifically the memory view that shows allocated memory, and breaks down the number of DOM nodes held in memory.
Some tests/demos along with provisional findings are provided here: chrome timeline exploration. The official documentation for Chrome’s dev tools is getting better, but could still use improvement. Hopefully this will go some way to providing a bit more insight into what’s going on, what different numbers mean, and what sort of behaviour you can expect from common scenarios.
As I’m nowhere near an expert of Chrome’s internals nor on memory profiling in general, any suggestions or corrections are more than welcome (pull requests or whatever).
Yes, Virginia, Google Chrome is fast. I installed it on my Windows XP work machine to give it a whirl, and it certainly rivals if not outperforms Firefox 3 in the speed department (though I haven’t found it to be as fast as some).
Hardware manufacturers everywhere must be thanking Google for this development. As this Slashdot article points out, both Internet Explorer 8 and Google Chrome aim to overcome the limitations that a single-process approach imposes on traditional browsers (i.e. more prone to irrecoverable crashes, less robust when running multiple web apps). What this means is that both IE8 and Chrome will be more resource intensive. Sure, you can have flickr, google maps, and photosynth running all at the same time in different tabs, but it will cost you in extra RAM and CPU overhead (not that this is surprising).
In any case, I’m sticking with Firefox 3 at least until Chrome is available for Mac and gets a comparable set of plugins.