Marking as Pri-1 since it sounds like a regression.

+erikchen who's doing perf and task manager stuff

I took a trace, looks like task manager causes ~500ms of work every 2s.

Deleted: trace_task_manager_cpu_usage.json.gz 970 KB

trace_task_manager_cpu_usage.json.gz 970 KB Download

The sample from comment 0 looks like most of the CPU usage goes into updating NSViews. The trace doesn't suggest that as far as I can tell (but maybe I'm misreading it).

In Chromium 59.0.3068.0 (which is what I have built on my machine) I'm only seeing ~2% of CPU going to task manager updates. Of that, 2/3 is to collect the metrics and 1/3 to display them.

Are you seeing an elevated amount of CPU because you have many tabs open, perhaps? And if you do have many tabs open, how do you know what percentage of browser CPU is going to servicing those pages vs. the task manager?

Because a) cpu usage goes up when task manager is open and down when it isn't b) the same in comment 0 shows that all the time is spent in updating the task manager ui.

I was wondering how you were determining CPU use when the Task Manager was offscreen.

Your sample does not show all time being spent updating the Task Manager - it shows that the main browser thread is spending all of its time updating the UI. I also don't see more than one repaint per update (per Quartz Debug) so I don't think the CPU use delta you're seeing is due to drawing.

Using Instruments on Chromium 59.0.3068.0 and with 20 tabs open (all Google search pages) I can see that 80% CPU is going to base::ProcessMetrics::GetMemoryBytes(). I'm guessing that Chrome creates a separate ProcessMetrics object for each process, and that GetMemoryBytes() is an expensive call. If you look at your sample you'll see time being spent in GetMemoryBytes() in the BrowserBlockingWorker3/64259 thread. The sample is useful for seeing seeing where threads are spending their time, but not so much for telling us how much CPU each is using (e.g. the main, BrowserBlockingWorker3/64259, and IOThreads are all busy during each sample but they are probably not doing the same amount of work).

I didn't check M57, so there may in fact be a regression there that's not present in M59. If you believe table redraw is chewing up lots of CPU, please use Instruments to sample your browser process so that we can see where the time is going.

If I'm correct about GetMemoryBytes() being the culprit, I'm not sure there's anything to be done on this bug.

Deleted: ChromiumBrowserProcessWith20Tabs.trace.zip 765 KB

ChromiumBrowserProcessWith20Tabs.trace.zip 765 KB Download

Thanks, I recently changed some of the internal logic here to use a slower, but more accurate accounting method:
https://codereview.chromium.org/2740423002/diff/40001/base/process/process_metrics_mac.cc

I eventually expect the task manager to just speak with the memory infra service, so I'd rather not spend too much time improving the performance here.

It doesn't seem like your changes have made GetMemoryBytes() more expensive that it already was.

But I changed the implementation of ProcessMetrics::GetWorkingSetSize to use GetMemoryBytes.

According to my trace and thakis@'s sample, task_manager::TaskGroupSampler::RefreshMemoryUsage() calls GetMemoryBytes() directly.

Ah, the same CL also changed that:
https://codereview.chromium.org/2740423002/diff/40001/chrome/browser/task_manager/sampling/task_group_sampler.cc

I'm confused then because thakis@'s M57 trace, which should predate your cl, says this:

    +             !     159 base::internal::Invoker<base::internal::BindState<task_manager::MemoryUsageStats (task_manager::TaskGroupSampler::*)(), scoped_refptr<task_manager::TaskGroupSampler> >, task_manager::MemoryUsageStats ()>::Run(base::internal::BindStateBase*)  (in Google Chrome Framework)  load address 0x1075f1000 + 0x18e5dca  [bind_internal.h:343]
    +             !       159 task_manager::TaskGroupSampler::RefreshMemoryUsage()  (in Google Chrome Framework)  load address 0x1075f1000 + 0x18e5c1e  [task_group_sampler.cc:134]
    +             !         133 base::ProcessMetrics::GetMemoryBytes(unsigned long*, unsigned long*)  (in Google Chrome Framework)  load address 0x1075f1000 + 0x19e0a60  [process_metrics_mac.cc:171]

Thanks for digging into this - I don't know why code in M57 would have that trace. 

> I was wondering how you were determining CPU use when the Task Manager was offscreen.

Close task manager, watch CPU usage drop in Activity Monitor (I think I'm misunderstanding the question, sorry.)

 Issue 713739  has been merged into this issue.

Taking out of mac triage - erik you seem to know most about what's going on - feel free to re-triage :)