Is the frame rate any more stable when using v-sync for begin/end frame?

I grabbed an ETW traces of about:blank with task manager open, taken on a Surface Book Pro. It showed the following minimum CPU usage for each (every second) task manager update:

Browser process: ~32 ms
GPU process:     ~16 ms
System process:  ~72 ms
DWM process:     ~10 ms

I listed the system and DWM processes because some amount of their work (especially DWM) is being triggered by Chrome, although it's hard to say how much.

The ~48 ms of CPU time in Chrome to do a task manager update is enough to cause frame rate hitches because it mostly happens during one ~20 ms period, thus interfering with whatever frame is being produced at the time.

The real question is whether there are any things that can be done to make task manager more CPU efficient. Looking at the trace a few things come to mind:

chrome.dll!task_manager::SharedSampler::RefreshOnWorkerThread - this was taking just a ms or two per update so we can ignore it
Rendering seemed to be the main cost. If there are easy ways to make rendering more efficient that would be great
I noticed a bit of time spent in chrome.dll!cc::StagingBufferPool::ReleaseBuffersNotUsedSince, which suggests that the buffers are allocated and freed every second. The cost for this is not huge, but it also triggers some other, more hidden costs. For instance, in chrome.dll!SkDraw::drawPaint about half of the time is spent faulting in pages - this happens because fresh buffers are being used each time.

The really hidden cost of freeing and reusing the buffers is that the freed memory needs to be zeroed before it can be reused and the system process does this. I blogged about the costs last year and came up with estimates for the three 'hidden' costs, of unmapping memory from the process address space, faulting it back in, and zeroing the freed pages:
https://randomascii.wordpress.com/2014/12/10/hidden-costs-of-memory-allocation/

Freeing the memory every time may be the right tradeoff, to avoid wasting memory, and the cost is not huge (probably only ~5 ms per update), but it seems worth assessing. And, there may be no other optimizations that are worth doing, given that the task manager is usually not open.

Any thoughts?

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

Assigning to current speed/power sheriff for triage.

I'm not able to reproduce this anymore. Bruce, are you?

*** UI Mass triage ***

adding labels for expert review.

Unable to reproduce the issue on Canary #72.0.3618.0

task manager was switched to use TaskScheduler 05/22/2017 and if I'm reading the release version history correctly, the first Chrome release with that change came out July 25, v 60. I can't reproduce this issue currently either.

Marking Fixed per #8.

If the task manager is sorted by a column whose values change frequently (e.g., CPU), then there is a brief drop in FPS every second, caused by having to repaint the task manager table view each time. Or at least that's what chrome://tracing seems to be saying. If sorted by a relatively stable column like pid, the FPS drops are not nearly as noticeable. I don't know how bad this was back in 06/17, and it's unclear from the comments how the task manager was sorted.