Scheduling profiler: Added lane labels and durations to React measures

[bvaughn]

• Increase height of React measures and add duration text inside of each measure.
• Add left-align labels to each row (e.g. "Retry", "Transition") to make UI easier to understand.

lane-labels.mp4

• Consider improving User Timing marks and parsing of lane-to-label map by explicitly logging the map along with each commit (rather than repeating the lane+label pair with each render/update mark).

The previous logging format used to log lane and lane-label info along with each of the following types of marks: state update scheduled, force update scheduled, render start, commit start, layout effects start, passive effects start. For example:

--render-start-16-Default

The new format explicitly logs the lane labels up front, and then later only logs the numeric value. For example:

--react-lane-labels-Sync,InputContinuousHydration,InputContinuous,DefaultHydration,Default,TransitionHydration,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Transition,Retry,Retry,Retry,Retry,Retry,SelectiveHydration,IdleHydration,Idle,Offscreen
...
--render-start-16

This may probably end up being about the same amount of data, but it solves a problem the previous logging format had: that lane labels could be ambiguous in certain data sets (see ed7f1d5).

Because this is a backwards breaking change, I also added an explicit version to the profiling data which the profiler now checks to ensure compatibility:

--profiler-version-1

I also added a mark for the React version too, although the profiler isn't yet displaying this info.

• Try rendering multi-lane (repeated) labels with a single text label.

[ryota-murakami]

I wonder if this unstable CircleCI can be improved somehow...
There are too many False Positive.

[sizebot]

Comparing: 19092ac...eab1b99

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	127.58 kB	127.58 kB	=	40.72 kB	40.72 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	130.40 kB	130.40 kB	=	41.65 kB	41.65 kB
facebook-www/ReactDOM-prod.classic.js	=	406.44 kB	406.44 kB	=	75.25 kB	75.25 kB
facebook-www/ReactDOM-prod.modern.js	=	394.80 kB	394.80 kB	=	73.52 kB	73.52 kB
facebook-www/ReactDOMForked-prod.classic.js	=	406.44 kB	406.44 kB	=	75.25 kB	75.25 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against eab1b99

[bvaughn]

I wonder if this unstable CircleCI can be improved somehow...
There are too many False Positive.

A lot of the failures from this PR were due to test flag permutations, but I agree with you in general. I think we've opted for speed on CI (with things like Yarn package caching) maybe at the cost of flakiness.

A lot of the flakiness lately seems to be due to transient NPM registry errors.

[jstejada]

this is awesome! just adding some noob questions

This may probably end up being about the same amount of data, but it solves a problem the previous logging format had: that lane labels could be ambiguous in certain data sets (see ed7f1d5).

just curious, could you elaborate a bit more specifically on what was ambiguous about the previous format? maybe an example would be helpful (sorry if obvious)

[bvaughn]

This may probably end up being about the same amount of data, but it solves a problem the previous logging format had: that lane labels could be ambiguous in certain data sets (see ed7f1d5).

just curious, could you elaborate a bit more specifically on what was ambiguous about the previous format? maybe an example would be helpful (sorry if obvious)

@jstejada Good question! Let's look at the old formatLanes function (before this PR):

react/packages/react-reconciler/src/SchedulingProfiler.js

Lines 62 to 70 in 19092ac

	export function formatLanes(laneOrLanes: Lane | Lanes): string {
	let labels = getLabelsForLanes(laneOrLanes);
	if (labels != null) {
	labels = labels.sort().join(',');
	} else {
	labels = '';
	}
	return `${laneOrLanes}-${labels}`;
	}

This logged work that was attributed to multiple lanes (like a render that had "entangled" work from more than one lane) in a format like this:

--render-start-<bitmask>-<lane-labels-joined-by-commas>

Usually work was attributed to only a single lane, e.g. --render-start-1-Sync. In this case, the lane-to-label mapping is unambiguous.

Sometimes work was attributed to more than one lane, but all with the same label, e.g. --render-start-50331648-Retry(s). In this case, the lane-to-label mapping is still unambiguous.

But if work was ever attributed to more than one lane, with different labels, the lane-to-label mapping would not be clear and we'd have to hope that each lane was unambiguously referred to somewhere else. This new format avoids that potential edge case.