Today is the Facebook IPO, so I pull up the live Bloomberg Radio feed on my computer.
But, due to technical problems, the IPO is delayed, so I pause the live audio stream and read some email. Then I notice that my computer is unusually busy.
Process Explorer (which I highly recommend for Windows users) is indicating that its running around 25% CPU utilization.
Like a shadow, a computer should do what you do (unless you are Steven Wright). Since reading email is not at all resource intensive, the computer should have been around 1% CPU utilization, if that.
Process Explorer identified Chrome as the CPU hog, but one of its rare failings is that it doesn't do a good job relating a Chrome process (and there are many) to a specific tab. For that, I turned to Chrome's own Task Manager*, which can be invoked three ways:
By default, you can't relate processes in the Chrome Task Manager with those in those in Process Explorer or the Windows Task Manager. But this is easily fixed by right clicking anywhere in the body of Chrome's Task Manager to reveal the full list of available data columns.
The important one, for this purpose, is Process ID. This is the same identifier that Process Explorer and the Windows Task Manager display as "PID".
The display can be sorted by any column; to find CPU hogs sort by CPU, to find memory hogs, sort by the Memory column. Column widths can also be adjusted as can the window size. Sadly, changes made to the display layout don't stick. Each time Chrome's Task Manager starts up, it reverts to the default layout shown above.
Chrome's Task Manager showed that the Bloomberg Radio page/tab was the culprit, even though the live stream was paused. Additional testing showed that the problem had nothing to do with audio, the main Bloomberg.com home page also consumed 25% of the CPU cycles on the machine.
Interestingly, when focus switches from the Bloomberg tab to another tab, CPU usage for Bloomberg drops back to negligible levels.
My guess was that the problem was the ticker streaming across the top of the page. In the screen shot below, the ticker is indicated by the red arrow.
Sure enough, hovering the mouse over the ticker stops it from moving and reduces CPU usage for the tab down to zero. There is also a Pause button on the far right (cropped out of the image above) that stops the ticker and the excessive CPU usage.
You may have heard that Chrome runs each tab in its own process. Its Task Manager shows that this is mostly, but not completely, true. When each tab is a different website, the rule starts out true, but at some point it breaks down and multiple tabs share a process.
Even before the rule breaks, multiple pages on the same site are allocated to the same process. You see this in the screen shot below, where each site has its own process, except computerworld.com which has three pages displayed by process 3484.
Each extension (at least those I use) also gets its own process as do Flash and Java. Flash is shown above as "Plug-in: Shockwave Flash". Despite the confusing name, this is Flash, not Shockwave. Java version 6 update 31, although not shown above, is identified as "Plug-in: Java(TM) Platform SE 6 U31"
That plugins get their own process, points the performance problem directly to the Bloomberg web pages, it was not an issue with a plugin. In fact, Chrome's Task Manager showed that the Bloomberg home page does not use either Flash or Java.
The Defensive Computing take-away is to use Chrome's Task Manager should the browser ever become non-responsive.
Chrome externalizes many statistics about each tab (see below) and one or more should be able to identify a problematic tab.
The "End process" button, at the bottom of the Task Manager display, can then be used to kill the offending tab without impacting other tabs.
Update: As for this particular performance problem, it gets more interesting.
To insure that this wasn't a fluke, I replicated the results on a second Windows 7 64 bit machine. Both machines were running Intel Core i5 processors (one was model M560, the other model 650).
Then an errand sent me to an Atom-based Windows XP netbook. While there, I brought up the Bloomberg website on Chrome. Surprisingly, all was well. The site hardly used any CPU cycles, after it had initially loaded.
Not only does the problem seem limited to Windows 7, it's also limited to Chrome (v19.0.1084.46). On the same pair of Windows 7 PCs, the Bloomberg.com home page does not use excessive CPU when viewed with Firefox 12 or Internet Explorer 9.
- - - - - -
Update 2. May 21, 2012: That there is an occasional performance problem with Chrome can be taken two ways. I still use it and recommend it; I'm willing to live with an occasional hiccup (nothing is perfect) because the advantages far outweigh the disadvantages.
Just the fact that Chrome has its own Task Manager illustrates my point. Neither of its main Windows based competitiors, Internet Explorer or Firefox offers one.
Chrome also uses processes to sandbox things much moreso than Firefox or Internet Explorer. Running so many distinct processes probably causes Chrome is to consume more RAM than other browers. I haven't tested this in detail, but even assuming it's true, the added safety offered by this extreme approach to sandboxing is one of many reasons that Chrome is my Defensive Computing browser of choice.
As for this particular issue, I can't find a pattern to it.
On another XP machine (32 bit), running a mobile Core 2 Duo T7100 processor, the results were inconsistent. Logged on as user1, Chrome 18 used around 50 percent CPU for the Bloomberg home page, after it had loaded. But logged on as user2, Chrome 19 had no performance problem with the Bloomberg site. Then, back to user1, and all is well this time. Thinking it may be a caching issue, I cleared the browser cache and restarted Chrome 18 (still as user1) and there was no performance problem.
Yet, I was able to repeat the 25% CPU usage on a third Windows 7 (64 bit) machine running a Core i5 (same as the first two Windows 7 machines that had the problem) model 2520m. But, even on the problematic Windows 7 machines, the performance problem happens most of the time, but not all the time.