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. Sure enough, hovering the mouse over the ticker stops it from moving and reduces cpu usage for the tab down to zero.
In the screen shot below, the ticker and the cpu usage are indicated by the red arrows.
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.
And that’s that … or so I thought.
To insure that the Bloomberg.com performance issue 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).
But then an errand sent me to an Atom based Windows XP netbook and 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.
Either Google, Bloomberg or Microsoft has some explaining to do.