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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=fea6949fdf0f15227cb9a6c4a70ff1bb27f847f9578bcfb0605dfe33b2e5ccee


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

webrtc-win-large-tests

Hi, these changes (mainly increased cpu usage) appear correlated with cl https://webrtc-review.googlesource.com/c/109009, "Fixing bug in SimulatedNetwork where packets stop."

Can you have a look? Is the simulated network used in these tests?

Yes, they are using FakeNetworkPipe. I guess the changes in the metrics could be cause by the changes in locking behavior. As quality metrics are unchanged I'll close this.

Any details on the changes in locking behavior? To me an increase in cpu load by 5 percentage points sounds like a *lot* of cycles if it's due to lock contention or something like that.

No, I don't know. Since it's a simulation effect I figure it shouldn't matter that much. If there's a need for better performance in that code, it's probably to add a feature request for that.

Hmm. You add one critsect to NextDeliveryTimeUs. Odd that it should have a large effect on cpu usage, maybe it's called a lot more often than it should? Anyway, if you think the increased cpu usage is in order, I'll leave it for now.