CodSpeed Instrumentation Performance Report

Merging #11535 will improve performances by 7.88%

_{Comparing ulrichstark:refactor-out-ast-kind-exceptions-of-jsx-types (91f0079) with main (896bdd9)}

Summary

⚡ 1 improvements
✅ 37 untouched benchmarks

Benchmarks breakdown

Less code and even some nice performance improvements 😎

⚡ linter[RadixUIAdoptionSection.jsx] 2.8 ms 2.6 ms +7.92%
⚡ semantic[RadixUIAdoptionSection.jsx] 72.4 µs 69.8 µs +3.64%

Banger!

Thanks so much for getting on this. It's a large PR, so will take me a while to get through reviewing it. But, on the face of it, looks great.

Actually, it wasn't so long. I've reviewed. From what I can see, looks good. But I'm not the best person to review the linter changes as I'm not so familiar with the linter.

1. @camc314 Could you possibly take a look at the linter changes (and not just the ones I've commented on)? As we're planning to drop Oxlint 1.0 next week, and make a big song and dance about it, it would be a really unfortunate moment to break things!

2. The reduced conformance pass rate in formatter suggests something may be wrong there. I know literally nothing about the formatter. @Dunqing Can you advise what we should do about that?

Note: The perf boost in Semantic I'm guessing is due to producing less AstNodes (the snapshot changes with lower NodeIds suggests that). I guess the boost in linter is just due to simpler code (less branches and lookups), but I'm amazed it has such a large effect. Bravo!

@ulrichstark Just to flag please don't get your hopes up that every further step we take on adding/removing AstKinds will get a similar perf boost. In some cases it'll probably result in more AstNodes, in others less. So perf may go up or down. But this is certainly a very pleasant first step down the road!

Not sure what's going on with the "Check links" CI fail. I've re-run it twice and it keeps failing on https://babeljs.io/docs/babel-plugin-transform-typescript, which seems to be a valid link.

There's no need to worry about the Formatter; I've created #11511 to revamp the Formatter core. I will revisit all AstKind use cases in Formatter after that work is done.

@camc314 merge after oxlint 1.0

Just did a commit to shorten the call to get the parent node kind. The other feedback around the two instances of is_within_jsx_attribute seems to be resolved? Is more work required from my side or are we good and wait for the oxlint 1.0 release?

Is more work required from my side or are we good and wait for the oxlint 1.0 release?

nope, i don't think so. I've checked both changes and they look fine. thanks for your work on this!

Nice work @ulrichstark!