[Proposal] Support event tracing for profiling

[kwonoj]

Discussed in #3065

^{Originally posted by kwonoj December 18, 2021}

Status	Last Updated	Target version
Accepted	Dec.19.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

[kwonoj]

A few tasks we can think of for the first implementation

• Expose new flag to enable traces. Will accept ['*'] as value only for now and it'll be boolean flag.
• Install chrome_layer into tracing subscriber with disabling default subscriber config
• Inject top-level span for each entrypoint (i.e transform)
• Flush strategy for tracing subscriber

Once this works properly, we can start auditing each individual creates to have correct span & traces.

[RiESAEX]

I looked into it a bit,
since tracing::span!() want a const value as it name, and most of visitors are chained by AndThen and Optional,
looks like we need to generate a visitor to wrap each AndThen/Optional we want to trace.

[kwonoj]

This is actually my planned work item, I'll dig a bit and come up with implementation proposal. Once we have reference implementation, we can make changes gradually as same as visit_mut refactoring.

[kwonoj]

@RiESAEX I choose to go with out of the box #instrument attr approach to mark most of overridden visitors. If we need custom spans, that can be dealt with separately either via span! or create span manually. #3731 illustrates it.

[RiESAEX]

just an idea
May be we can create a macro to reduce copy&paste of #[tracing::instrument(level = "trace", skip_all)]
like

#[trace] // it generate #[tracing::instrument(level = "trace", skip_all)] for every implemented visit_mut_*
impl VisitMut for Arrow {}

[kdy1]

@RiESAEX I think it's good to have, and it can be language-agnostic if we only need to add the #[instrument] only for existing methods

[kdy1]

Done with #3738

[Nathamuni]

ORUVELE IRUKUMO...

[kwonoj]

This is reasonably achieved for the transform interface. minify / others are different but have other tracking issue.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.