Wp-calypso: Framework: Calypso pages freeze or crash

[gwwar]

Since late September, we've been seeing poor performance. During fresh page loads, the page can sometimes freeze or crash without any active user activity. We should take the time to profile and see if we can discover any new bottlenecks. If anything stands out, please create new issues to address them specifically.

Performance Profiling

• I would recommend using the Chrome performance tool.
• For clearest results, please also use a clean browser environment (no plugins), in a non-dev environment (docker). We use certain tools in development environment like redux logging that may slow things down.
• List clear steps that you take to trigger client load
• Provide the timeline dump if possible for other people to inspect
• See https://github.com/Automattic/wp-calypso/pull/10836#issuecomment-274628155 as an example

[apeatling]

I just experienced the freeze, and managed to have the Google Chrome performance profiler running. Here's what I saw:

The execution tree seemed to bring it all the way down to this bit of code causing the delay:

I have saved the profiler file for when we tackle this.

[ockham]

The execution tree seemed to bring it all the way down to this bit of code causing the delay: [...]

Looks like https://github.com/Automattic/wpcom-proxy-request/blob/d31b02d14495c73a3ffd52946a5df3fa06d5dd5f/index.js#L393

[klimeryk]

Possibly related: https://github.com/Automattic/wpcom-proxy-request/pull/30

[jsnajdr]

I found the issue captured by @apeatling in the profile above:

• if SitesList.sync is called with a list of 50 sites, it will dispatch 50 individual receiveSite Redux actions to update each site
• each of these dispatches will replace state.sites.items with a new array
• after any update of state.sites.items, the getSite selector forgets all memoized values of all sites, and recomputes them from scratch for each individual value of siteId
• the recomputed value is a different object, although deeply equal to the old value. All connected components will be rerendered.

When loading the /stats/day/:siteId page in my account with 54 sites, during the call to SitesList.sync some mapStateToProps function is called 11125 times, and 4725 of them return a new value of props that trigger a rerender of something.

Right now, I'm working on improving the memoization of getSite that should slash a large number of the rerenders.

If the getSite selector has memoized a value for site ID 123, and state.sites.items is updated with site ID 456, the value of state.sites.items[123] is still the same: we shouldn't throw away the memoized value that has been computed from it. (we add some computed attributes to the raw site object before returning)

More optimizations will surely be coming after that.

[blowery]

hah! I was looking at the wrong sites.sync! 😄

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.