API changes to make swc faster

[kdy1]

I have several questions. I want to change APIs to make swc faster, but most of the optimization is about restricting API surface.

So I want to check if there's someone actually using those APIs.

• Do you think there's any problem with the AST definition (regarding performance)?

I don't have a concrete optimization idea about it at the moment, but just want to check.

• Do you think the Input trait is worth it?

It exists to support streaming parsing, but I'm not sure if it is worth it. It blocks optimization like SIMD.

• Did you use the ParserInput API of swc?

Especially Capturing and the fact that Token is exposed block lots of optimization.

[g-plane]

Do you think there's any problem with the AST definition (regarding performance)?

While leveraging Box to reduce type size, using unstable "box_pattern" feature would require nightly Rust toolchain, which causes downstream projects have to use nightly toolchain as well.

Do you think the Input trait is worth it?

I'm not sure, but I never use it directly. I don't use streaming parsing, and at least for me, I use String/&str, but I'm not sure whether it affects some types like Arc<String> and Cow<str> or not if removing Input trait.

Did you use the ParserInput API of swc?

I even haven't heard of it.

[Boshen]

I found a bottleneck I think blocked by API design I think.

Currently we need to clone the source text and pass it into swc:

swc/crates/swc_common/src/syntax_pos.rs

Lines 841 to 842 in e93c79b

	/// The complete source code
	pub src: Lrc<String>,

But in theory, and my own experience from studying and working on Rome, Oxc and mozilla-spidermonkey/jsparagus, it is sufficient for parsers to run on string references instead of an allocated string.

This has become a bottleneck for Rspack because we are processing 10,000+ files in parallel, so removing source text clones will help a lot on the memory allocator.

[kdy1]

You can use &str with StringInput, but then the problem is the source map...