ResourceDispatcherHostImpl::UpdateLoadInfo takes 2.471% of CPU on the browser IO thread |
|||
Issue descriptionSampling profiler data for 68.0.3415.0 [1] says that ResourceDispatcherHostImpl::UpdateLoadInfo takes 2.471% of CPU on the browser IO thread. Private data from other sampling profiler analysis has some cases where ResourceDispatcherHostImpl::UpdateLoadInfo takes 4.098% of CPU on the browser IO thread. It seems that there are some low-hanging optimization opportunities: 1. Don't create a temporary/short-lived |std::map frame_infos| in ResourceDispatcherHostImpl::GetInterestingPerFrameLoadInfos. Instead put all the map contents into a flat std::vector, sort the vector by map's key and dedupe via LoadInfoIsMoreInteresting at that point. 2. Have ResourceDispatcherHostImpl::GetInterestingPerFrameLoadInfos preallocate/reserve the required capacity for the |infos| vector (there can't be more than |pending_loaders_.size()|) and then shrink at the very end. [1] https://uma.googleplex.com/p/chrome/callstacks/?sid=b762298ce464c98462b1fdb0ee589493
,
May 2 2018
Thanks lukasza, these are great ideas. As mmenke says the code is going away soon so it isn't super high priority though. Still, I may look into it more if I get some time. There's another dead-simple "optimization" which is to call UploadLoadInfo less often. It is called on a 250ms timer.
,
May 2 2018
Note that the timer is done before the first update, so I'm not sure we can just increase it (It used to be 100 milliseconds, actually), since that adds more time to the "chrome does not respond in any way to new navigation, other than spinning" time window. I assume we delay the first call to avoid hammering the CPU if we keep on having only one very-short-lived request at a time.
,
May 2 2018
AFAICT, the call is guarded by a timer in all cases, not just the first one.
,
May 2 2018
It is, I just mean that the timer also delays the first call. So if we used a timer of 20 minutes, people would generally never see the loading status.
,
May 9 2018
Seems out of scope of network bug triage. |
|||
►
Sign in to add a comment |
|||
Comment 1 by mmenke@chromium.org
, May 1 2018