feat(mangler): reuse variable names

[sapphi-red]

Changed the mangler to reuse variable names where possible.

This will reduce the code size as shorter variable names can be used in more places. But requires global information and limits parallelism in a single file and requires more memory.

[sapphi-red]

• feat(mangler): reuse variable names #8562 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Performance Report

Merging #8562 will degrade performances by 74.8%

_{Comparing 01-17-feat_mangler_reuse_variable_names (98a95b4) with main (8587965)}

Summary

❌ 3 regressions
✅ 30 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	mangler[antd.js]	6 ms	14.2 ms	-57.43%
❌	mangler[react.development.js]	139.4 µs	290.1 µs	-51.94%
❌	mangler[typescript.js]	9.6 ms	38 ms	-74.8%

[sapphi-red]

The perf regression looks really bad, but if you take a step back and see the overall minifier timings, it's not that big regression.

antd: 196.8ms (6.4ms is 3.3%)
react: 1.8ms (125.1µs is 7.0%)
typescript: 344.6ms (24.9ms is 7.2%)

[overlookmotel]

Just to raise one other concern:

The addition of scope_id field to Reference will cause difficulties in transformer. In transformer, we update semantic data as we mutate the AST, to keep AST + semantic in sync.

This is quite difficult already, and if Reference has a scope_id field, we'd need to update that field too whenever we move an IdentifierReference into a different scope, or e.g. wrap some code in an IIFE (which introduces a new scope). Both of these are fairly common operations in the transformer.

The changes to TraverseScoping::create_bound_reference and create_unbound_reference in this PR aren't correct - often we are creating a Reference in a different scope from the current one.

FYI: The bigger picture is: Currently we run semantic analysis multiple times during the pipeline. The hope (well certainly my hope) is that we can eventually make all stages of the pipeline keep semantic data in sync with AST changes. Then we'll be able to remove these extra semantic passes, which will be a large perf improvement.

---

The performance issue needs to be looked at first. But if we decide that it's worth it (very possibly it is), I would suggest the following:

• Split the introduction of Reference::scope_id field into a separate PR.
• Add checks for correctness of that field to the transformer conformance checker (which checks semantic data is correct after transform), and see how many errors we have due to incorrect Reference::scope_id.
• Assess how much work required to handle updating this extra state in transformer.

It will of course be achievable with some effort, but it'd be useful to understand how much effort before we go ahead. Maybe it's easier than I think!

cc @Dunqing

---

Last thing: I'm not very familiar with the mangler. Could you possibly give a brief explanation of how this algorithm works? I'm wondering if any other way to achieve the effect without the Reference::scope_id field.

[Dunqing]

This is a significant minification improvement. I've thought about this before, but I have the same concern as @overlookmotel.

I am guessing the smaller output is more important than performance here? So I think we can add an extra AST pass to collect identifier references that belong to which scope, this way we can only change in the mangler crate.

[sapphi-red]

The addition of scope_id field to Reference will cause difficulties in transformer. In transformer, we update semantic data as we mutate the AST, to keep AST + semantic in sync.

Yeah, I had that concern while writing this code. I went this way at that time to see how much this change would improve the minification rate.
@Dunqing 's idea of collecting the scope_ids of the references before running the mangler sounds worth exploring.

Could you possibly give a brief explanation of how this algorithm works?

This PR introduces a concept of "liveness". This is the set of scopes that a given variable / slot is used in.
For example, if we have the following code:

var top_level_a = 0;
var top_level_b = 1;

function foo() {
  var foo_a = 1;
  console.log(top_level_b, foo_a);
}

function bar() {
  var bar_a = 1;
  console.log(top_level_b, bar_a);
}

console.log(top_level_a, foo(), bar())

Each liveness of the variables will be:

• top_level_a: {root}
• top_level_b: {root, foo function, bar function}
• foo_a: {foo function}
• bar_a: {bar function}
• foo: {root}
• bar: {root}

Since top_level_a is only used in the root scope and foo_a is only used in the foo function and bar_a is only used in the bar function, foo_a and bar_a can shadow top_level_a.
In other words, since the liveness of top_level_a and foo_a and bar_a does not overlap, they can be assigned to the same slot.

For this example, the slots assigned to the variables will be:

• slot 0: top_level_a
• slot 1: top_level_b, foo_a, bar_a
• slot 2: foo
• slot 3: bar

[Boshen]

@sapphi-red To be honest I spent the last hour and still don't comprehend any of this ... probably due to my lack knowledge of JavaScript.

May I ask you a favor. Can you update the top level documentation, reference all reading materials, and write a line by line explanation for your newly added code? Just like how I did it with the next one ... so the next person can understand what's going in.

I'll do some micro optimizations.

And also ... is the debug mode still useful or should it be adjusted?

[Boshen]

CodSpeed Performance Report

Merging #8562 will degrade performances by 75.24%

Comparing 01-17-feat_mangler_reuse_variable_names (faaa1ee) with main (b977678)

Summary

❌ 3 regressions ✅ 29 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark BASE HEAD Change
❌ mangler[antd.js] 6 ms 14.6 ms -58.67%
❌ mangler[react.development.js] 139.2 µs 295.6 µs -52.91%
❌ mangler[typescript.js] 9.6 ms 38.7 ms -75.24%

oxc  main ❯ hyperfine './target/release/examples/mangler --nospace --mangle ./target/typescript.js' './target/release/examples/minifier --nospace --mangle ./target/typescript.js'
Benchmark 1: ./target/release/examples/mangler --nospace --mangle ./target/typescript.js
  Time (mean ± σ):     142.2 ms ±   1.1 ms    [User: 129.1 ms, System: 11.4 ms]
  Range (min … max):   140.9 ms … 145.8 ms    20 runs

Benchmark 2: ./target/release/examples/minifier --nospace --mangle ./target/typescript.js
  Time (mean ± σ):     137.5 ms ±   0.5 ms    [User: 125.2 ms, System: 10.6 ms]
  Range (min … max):   136.4 ms … 138.3 ms    21 runs

Summary
  ./target/release/examples/minifier --nospace --mangle ./target/typescript.js ran
    1.03 ± 0.01 times faster than ./target/release/examples/mangler --nospace --mangle ./target/typescript.js

Only 5ms for typescript.js

[sapphi-red]

I added a comment that describes the algorithm and added some test cases. I hope that my explanation makes sense, but let me know if there's any places that are unclear.