There are some noteworthy rough edges:

1. I haven't thought through how to separate/combine the traces for different projects in build mode, so presently I just insert a counter into each path to prevent clobbering.
2. The new System APIs are ugly, but I think it's important to write as you go, so that you get something if you have to kill a very long build (e.g. customers reporting tens of minutes)
3. Some types are still only readable by means of typeToTypeNode and I'd really like to eliminate that because of how slow it is (not urgent since it happens after profiling is complete)

Updates:

1. Only use counters in build mode and print a separate legend file mapping them back to tsconfig paths.
2. Reverted - @RyanCavanaugh suggested using fs directly.
3. Will likely wait for a future PR.

CI failures are because I didn't update the harness System impl(s). That can wait until next week.

There are deliberately few trace events in the checker to avoid (excessively) skewing the runtime. If people would like to see more, e.g. for debugging, my inclination would be to add a separate mode (i.e. profiling trace vs activity trace). Note that the persistence format is JSON, so it's very easy to create enormous trace files (e.g. adding inferFromTypes tripled the file size for one sample project).

Have you looked at the sources for ts-perf? I made some headway doing the same thing with the existing performance.mark function and have code for generating Chrome timelines.

Rough instructions for using it in its present state:

1. Append --generateTrace {folderName} to your regular tsc command line
2. Look in the resulting folder. If you used build mode, there will be a legend.json telling you what went where. Otherwise, there will be a trace.json file and a types.json files.
3. Navigate to edge://tracing or chrome://tracing and Load trace.json
4. Expand Process 1 with the little triangle in the left sidebar
5. Click on different blocks to see their payloads in the bottom pane
6. Open types.json in an editor
7. When you see a type ID in the tracing output, go-to-line {id} to find data about that type

Having applied this to several repos now, I feel pretty confident that this is useful in its current state. Enriching it with additional tracepoints (e.g. for inference) or output (e.g. stack traces) can follow in future PRs.