This seems bad. Can you attach a trace from chrome://tracing?

The problem is the Elide calls. Supposedly never designed to be used for a lot of fields.

If this is mac-specific, maybe avi has thoughts.

I don't understand how this would be Mac. The class TableView and the call RenderTextHarfBuzz:EnsureLayoutRunList are Views-only, while the Mac Task Manager uses a native NSTableView.

OP, can you clarify on what platform you're seeing this? Is this on Windows? Linux? Mac with the MacViews flag turned on? This doesn't make sense to me for the default Mac config that we ship.

It was on Windows. I didn't consider that the code could be different on different operating systems. 

I'm taking off the "Mac" tag, as the Mac and Views Task Managers do not share code.

... do not share UI code. (They share the backend code, but that's not what this is about.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Possibly the same underlying problem as  issue 737304 . Whaddya think, brucedawson?

It sounds similar indeed.

Assigning to brucedawson@, current primary for Chrome Power, to triage further.

Assigned to David. He'll figure out what is going on and what can be improved. Some of the fixes may be cross-platform.

One possible change would be to move the task manager out-of-proc. This would solve the problem of it being impossible to use Chrome's task manager to see how much CPU time the browser process is using, in a way that no amount of optimization will ever do.

WPA turned out to be quite helpful here - DrawStringRectWithFlags is getting called much more often than expected. It turns out that we're trying to paint all rows, ignoring whether they're visible or not. TableView::GetPaintRegion is using the canvas getLocalClipBounds instead of the VisibleBounds of the view, when determining how many rows to paint. Using VisibleBounds seems to work for the taskmanager, but there are other clients of TableView that might not, I suppose. So I'll have to check with sky@ about the right way to fix this.
It's also quite possible that we're painting more frequently than we need to, but definitely the low hanging fruit is to only paint the visible rows.

Excellent discovery. One caution however. You said "WPA turned out to be quite helpful here - DrawStringRectWithFlags is getting called much more often than expected" - but WPA doesn't tell you how often a function was called (usually). Specifically, CPU Usage (Sampled) shows you how many samples hit inside a function/call-stack, but it generally can't distinguish between one call to a slow function and many calls to a fast/medium function.

Ah, OK, good to know. In this case, this function is generally fast, but called frequently. FWIW, I turned on fast sampling, and used the CPU usage (precise) graph.