[Proposal] Support event tracing for profiling

[kwonoj]

Status	Last Updated	Target version
Accepted	Dec.18.2021	TBD

Summary

Expose a new flag, --trace or similar to emit profiling trace for SWC's internal behavior as trace event format.

Motivation

Performance is one of the notable characteristics of SWC. While SWC itself needs to deliver consistent peak performance, there will be problems from end user's codebases. By providing trace capabilities from SWC's core itself user can have detailed diagnostics to their own problem, also it can be used for the tracing for observability.

Slack for example heavily utilizes chrome's tracing feature for internal perf analysis (https://slack.engineering/chrome-tracing-for-fun-and-profit/) for their desktop client to solve real world user performance issue cannot be reproducible internally.

Explainer

Trace Event format is JSON representation of trace event data can be processed via various tools, including trace viewer. Chrome uses it for its trace profiling (https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) as well as other tools like Bazel (https://docs.bazel.build/versions/main/skylark/performance.html). Chrome has an embedded trace viewer for the visualization (chrome://tracing/).

Detailed design

Thankfully, there are rust ecosystem allows us to adapt this easily. Moreover, SWC already have tracing (https://github.com/tokio-rs/tracing) internally. There is a layer tracing_chrome (https://github.com/thoren-d/tracing-chrome) on top of tracing subscriber which generates Event Trace Format JSON output from existing traces.

This PR (#3066) have quick & dirty poc demo which enables chrome traces with few dummy spans for transform_sync. Please refer generated JSON for the output format which can be visualized as below.

As a consumer's point of view, I expect these kinds of pseudo workflow to generate traces for a given operation.

// run @swc/cli
npx swc ./file.js ...options --trace categories1, categories2

// run @swc/core
import * as swc from '@swc/core';

swc.transformSync(code, {
  ...options,
  diagnostics: {
    enableTrace: ['*']
  }
});

• Each trace request applies to a single operation. There will not be a global config / or function to override every operation in the scope.
• Trace will offer categories: this indicates which part of trace will be recorded. For example, there can be categories like ecma_parser / ecma_transforms. As illustrated in second example, it is possible to apply some wildcard behavior. This mimics chromium's behavior for its categoryFilter
• Trace does not offer way to customize its output including its path, by default it'll create random-name file under cwd.

Drawbacks

• There'll be notable amount of effort to rewrite some of the traces as well as adding new one

Alternatives

Not much. Do not think it is worth to invent something new for swc only especially we have some of infrastructures in our codes.

Unresolved questions

There are multiple open questions / tasks that need to be resolved to make this happen. Notably,

• Should release build offer tracing capabilities
• Performance impact if release build supports trace
• Adjust, write, update span across all codebase to create correct traces
• Managing trace flushing
• CategoryFilter support: first version may not support this, instead behaves as simple toggle

[kdy1]

I love this idea.
I don't expect the perf impact of this change to be problematic, but we should profile anyway.

[kwonoj]

Thoughts on moving this into issue and track for further implementation? I don't think we have specific target release date yet, but at least can start work on some foundational work like chaining chrome_layer with new config options.

[kdy1]

I think making an issue for this is a good idea.

[kwonoj]

#3071 will track this effort.