RDH: Add some more instrumentation to figure out jank in RDH.

RDH: More instrumentation for jank in GetLoadInfoForAllRoutes.

Getting and updating the load state of requests is janky.

TBR=eroman@chromium.org
BUG=455952
Committed: https://crrev.com/0156831a6f278576422bbd6e87105d506e5f5224
Cr-Commit-Position: refs/heads/master@{#318525}

[mmenke, 2015-02-27 17:42:43]

Patchset #2 (id:20001) has been deleted

[mmenke, 2015-02-27 21:19:05]

mmenke@chromium.org changed reviewers:
+ eroman@chromium.org

[mmenke, 2015-02-27 21:19:06]

Eric:  Just going to TBR this one since it just adds a few more ScopedTrackers
to try and get to the bottom of the RDH LoadInfo jank, and pkasting's been
TBRing CLs like this.  Hope that with this, we'll finally have a picture of just
what's going on.

[eroman, 2015-02-27 21:25:52]

https://codereview.chromium.org/966813002/diff/1/content/browser/loader/resou...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/966813002/diff/1/content/browser/loader/resou...
content/browser/loader/resource_dispatcher_host_impl.cc:2188:
tracked_objects::ScopedTracker tracking_profile4(
I would suggest measuring TimeTicks manually for these sections, and accumulate
it over the entire pending_loaders_ before reporting it to the profiler.

The reason I suggest that is it might be more of the multiplicative effect that
leads to the jank than any individual one.

Either way, LGTM

[mmenke, 2015-02-27 21:50:22]

https://codereview.chromium.org/966813002/diff/1/content/browser/loader/resou...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/966813002/diff/1/content/browser/loader/resou...
content/browser/loader/resource_dispatcher_host_impl.cc:2188:
tracked_objects::ScopedTracker tracking_profile4(
On 2015/02/27 21:25:52, eroman wrote:
> I would suggest measuring TimeTicks manually for these sections, and
accumulate
> it over the entire pending_loaders_ before reporting it to the profiler.
> 
> The reason I suggest that is it might be more of the multiplicative effect
that
> leads to the jank than any individual one.
> 
> Either way, LGTM

Good point.  For now, I think I'll just do this and look at aggregate CPU usage
(Which, admittedly, is much different from "jank").  Could end up improving the
average case but not the worst/janky case, but this method is up there when it
comes to total runtime on the IOThread, too, so I don't think that would be a
waste of time.

Admittedly, being one of the largest aggregate consumers of CPU time on the IO
thread doesn't exactly mean it consumes a huge amount of CPU time in an absolute
sense, but it really shouldn't be up there.

[mmenke, 2015-02-27 21:50:43]

The CQ bit was checked by mmenke@chromium.org

[commit-bot: I haz the power, 2015-02-27 21:51:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/966813002/1

[commit-bot: I haz the power, 2015-02-27 22:01:36]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-27 22:02:28]

Patchset 1 (id:??) landed as
https://crrev.com/0156831a6f278576422bbd6e87105d506e5f5224
Cr-Commit-Position: refs/heads/master@{#318525}