1369125 - Jank in the parent process due to too much telemetry accumulation when interacting with large tables

Status: RESOLVED DUPLICATE of bug 1369141

(Core :: General, defect)

Description

[Markus Stange [:mstange]]

[Tracking Requested - why for this release]: Serious performance regression

This is a very recent regression. I'm going to get a regression range in a second.

Profile: https://perfht.ml/2rkDaWZ

Steps to reproduce:
 1. Load https://hg.mozilla.org/releases/mozilla-beta/annotate/cf76e00dcd6f/layout/painting/FrameLayerBuilder.cpp#l5618
 2. Slowly scroll up and down
 3. Notice the jank

Comment 1

[Markus Stange [:mstange]]

I didn't get very far:
> 6:27.11 INFO: Got as far as we can go bisecting nightlies...
> 6:27.11 INFO: Last good revision: 0b255199db9d6a6f189b89b7906f99155bde3726 (2017-05-05)
> 6:27.11 INFO: First bad revision: 37a5b7f6f101df2eb292b1b6baaf1540c9920e20 (2017-05-06)
> 6:27.11 INFO: Pushlog:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b255199db9d6a6f189b89b7906f99155bde3726&tochange=37a5b7f6f101df2eb292b1b6baaf1540c9920e20

and then it failed to find inbound builds.

I had to start mozregression with --pref toolkit.telemetry.enabled:true because it sets that pref to false by default.

Comment 2

[Markus Stange [:mstange]]

There seem to be multiple issues here.

The first issue is that hit testing in big tables has become extremely slow after bug 929484. I've filed bug 1369141 about that.
On my machine, every RecvMouseWheelEvent and RecvRealMouseMoveEvent invocation takes 30ms on this page.
My guess is that this activates the slow paint telemetry. Then for some reason, we accumulate lots of telemetry data.
And then we send that to the parent process, which seems to be surprisingly slow at processing that data.
For example, 20% of internal_GetHistogramEnumId is spent building up strings. https://perfht.ml/2rkW1RM

Comment 3

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #2)
> My guess is that this activates the slow paint telemetry. Then for some
> reason, we accumulate lots of telemetry data.

It's not the slow paint telemetry. It's the DISPLAY_ITEM_USAGE_COUNT telemetry. nsDisplayList::DeleteAll() calls Telemetry::Accumulate for every single item in the display list, and I could see that being slow if you have lots of items.

Comment 4

[Markus Stange [:mstange]]

Removing tracking-firefox55 request in favor of the one in bug 1369141.

Comment 5

[Andrew Overholt [:overholt]]

Do we still need this in 55 given bug 1369141 is fixed?

Comment 6

[Markus Stange [:mstange]]

No we don't. This is fixed. I'm going to mark it as a duplicate of bug 1369141.