feat(tools-performance): Add @rnx-kit/tools-performance package

[JasonVMo]

Description

This adds a framework for doing lightweight performance tracing, some basic reporting, and enabling tracing at a global level.

Usage

In packages, to add instrumentation:

import { getTrace } from "@rnx-kit/tools-performance";

async function myFunction() {
  // will return a logging tracer if "transform" is enabled, a passthrough if not
  const trace = getTrace("transform");
  // trace a sync closure
  const result1 = trace("func1", () => doSomething(p1, p2));
  // trace a sync function without creating a closure
  const result2 = trace("process result, doSomethingElse, result1, options);
  // trace an async function and return
  const final = await trace("call async", finalCall, result2);
  return final;
}

Right now, to enable this for metro bundling a user would add in their metro.config.js:

import { trackPerformance } from "@rnx-kit/tools-performance";

// these would all work
trackPerformance("transform"); // only turn on this one area
trackPerformance(["transform", "metro"]); // turn on a set of areas
trackPerformance(/* or true */); // turn on all performance tracing

Future things to add (or consider)

• instrument various parts of our infrastructure
• add an implementation of unstable_perfLoggerFactory that hooks into this
• have our metro config automatically add the unstable_perfLoggerFactory if "metro" is enabled
• consider adding a cli option that will enable perf logging for our tools automatically

Other notes

• text is styled using the formatting from node:utils
• simple table formatting in the same format as console.table is added, except with support for formatted text.

[tido64]

Suggested change

	return defaultManager?.isEnabled(category) ?? false;
	return Boolean(defaultManager?.isEnabled(category));

[tido64]

Can we use performance.mark and performance.measure instead of manually recording time? https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure#examples

Another added benefit is getting tracking for free: https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries

[JasonVMo]

I'm reworking this a bit to be cleaner and will support both. The perf markers are heavier than timing based ones and have memory bloat issues. Instrumenting babel plugins with them would run out of memory. It only takes a slight adjustment to make either work.

[tido64]

Remove

Suggested change

<!-- We recommend an empty change log entry for a new package: `yarn change --empty` -->

[tido64]

Do you plan to implement this in this PR or later?

[JasonVMo]

Old comment. Will clean it up in the next iteration.

[tido64]

Avoid force nonnull assertion. Rewrite to help TypeScript infer nullability:

Suggested change

	export const exitHandler = (() => {
	let callbacks: (() => void)[] | undefined = undefined;
	function add(callback: () => void) {
	if (!callbacks) {
	callbacks = [];
	process.on("exit", () => {
	for (const cb of callbacks!) {
	cb();
	}
	});
	}
	callbacks.push(callback);
	}
	type OnExit = () => void;
	export const exitHandler = (() => {
	let callbacks: OnExit[] | undefined = undefined;
	function add(callback: OnExit) {
	if (!callbacks) {
	const arr: OnExit[] = [];
	process.on("exit", () => {
	for (const cb of arr) {
	cb();
	}
	});
	callbacks = arr;
	}
	callbacks.push(callback);
	}

[tido64]

Should we be using Set<OnExit> instead to ensure uniqueness and gain access to .delete()?

[tido64]

We should probably also check that category is an actual array:

Suggested change

	} else {
	for (const cat of category) {
	this.enabled.add(cat);
	}
	}
	} else if (Array.isArray(category)) {
	for (const cat of category) {
	this.enabled.add(cat);
	}
	} else {
	throw new Error(`invalid category: ${category}`);
	}

[tido64]

These should return undefined since we're already handling nullable in the module-level getRecorder/getTrace methods.