perf(napi/oxlint): optimize compiling visitor

[overlookmotel]

Optimize merging together visitors from multiple rules.

The merging itself is a bit faster. More importantly, the merged visitor functions are more optimizable by the JS engine, which makes calling them less expensive.

In a benchmark running 3 rules which all visit the same common AST nodes (identifiers) on VS Code repo, this speeds up lintFile by 30% on average, giving an overall speed-up of 15% (when no built-in Oxlint rules enabled).

[overlookmotel]

• perf(napi/oxlint): optimize compiling visitor #12472 👈 (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.

[camc314]

this is crazy

[camc314]

Merge activity

• Jul 23, 1:17 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jul 23, 1:18 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Jul 23, 1:26 PM UTC: Merged by the Graphite merge queue.

[overlookmotel]

@camc314 This can change the order that rules run in, so output diagnostics can appear in different order from the order the rules are defined in config. I don't think that matters, right?

If it does, could amend this PR to ensure rules run in original order. It'd just make compiling visitors a little slower.

[camc314]

no, rule order doesn't matter

[camc314]

Let me add a check so that when running tests, we always sort the diagnostics

Actually sorting is really hard as it'll interfere with the other diagnostics

[overlookmotel]

The order rules run in (and therefore order they output diagnostics) is deterministic. It's just not necessarily in the order the rules are defined in config.

Obviously, determinism will go out the window once we introduce multi-threading! (although that'll affect the order files are linted in, not the order rules run in for each file)

[camc314]

Oh you've actually hit an edge case:

oxc/apps/oxlint/src/output_formatter/default.rs

Lines 135 to 136 in 1d2eaca

	self.diagnostics.sort_by_key(|diagnostic| Info::new(diagnostic).filename);
	self.diagnostics.sort_by_key(|diagnostic| Info::new(diagnostic).start.line);

we already sort by filename, start/end line. but since these both have the same filename/start/end line, the order changes