All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=696996

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgxOymvAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgxOzNsgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDguIrOswkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDghJ6qogsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDghPrBpQoM


Bot(s) for this bug's original alert(s):

webrtc-mac-large-tests

Stefan, Bjorn - I need your help to understand what these changes really mean :)

From what I can tell, the difference seems to be that the change introduced in my CL, removes a call to sched_yield() that was implicitly there, and uses only the done_.Wait(kSendStatsPollingIntervalMs) check that was already in PollStats().
See here:

https://codereview.webrtc.org/2708723003/diff/80001/webrtc/video/video_quality_test.cc?context=50

Looking at the perf data from the bots, I don't see the "cpu_usage" field being recorded, but I do see that locally and there seems to be a slight improvement there, not a regression.

As far as 'encode_usage_percent' goes, there appears to be an improvement for foreman_cif_30kbps_net_delay_0_0_plr_0 whereas there's a regression for foreman_cif_500kbps_32pkts_queue.

Are these tests perhaps very sensitive to when exactly the stats are polled?

They could be sensitive, but I don't know for sure, Åsa probably knows better.