perf(transformer/jsx): use memchr for parsing JSX pragma comments

[overlookmotel]

Use memchr for finding @ when parsing JSX pragmas from comments.

This wins back most (but not all) of the perf loss of #10983 on antd.js benchmark, and preserves the perf gain of #10983 on cal.com.tsx benchmark.

Interestingly, using memchr to search just for @ and then checking next 3 bytes are jsx separately is measurably faster than using memchr::memmem::Finder to search for @jsx.

[overlookmotel]

• perf(transformer/jsx): use memchr for parsing JSX pragma comments #11001 👈 (View in Graphite)
• test(transformer/jsx): fix tests for JSX pragma parsing #11000
• 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 Instrumentation Performance Report

Merging #11001 will create unknown performance changes

_{Comparing 05-13-perf_transformer_jsx_use_memchr_for_parsing_jsx_pragma_comments (1aed99b) with main (6540f44)}

Summary

🆕 36 new benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
🆕	codegen[checker.ts]	N/A	22.8 ms	N/A
🆕	codegen_sourcemap[checker.ts]	N/A	67 ms	N/A
🆕	formatter[antd.js]	N/A	714.8 ms	N/A
🆕	formatter[react.development.js]	N/A	8.1 ms	N/A
🆕	formatter[typescript.js]	N/A	1.1 s	N/A
🆕	isolated-declarations[vue-id.ts]	N/A	58.5 ms	N/A
🆕	lexer[RadixUIAdoptionSection.jsx]	N/A	21.7 µs	N/A
🆕	lexer[antd.js]	N/A	25 ms	N/A
🆕	lexer[cal.com.tsx]	N/A	6.1 ms	N/A
🆕	lexer[checker.ts]	N/A	14.9 ms	N/A
🆕	lexer[pdf.mjs]	N/A	4 ms	N/A
🆕	linter[RadixUIAdoptionSection.jsx]	N/A	2.8 ms	N/A
🆕	linter[cal.com.tsx]	N/A	1.2 s	N/A
🆕	linter[checker.ts]	N/A	3.1 s	N/A
🆕	mangler[antd.js]	N/A	16 ms	N/A
🆕	mangler[react.development.js]	N/A	295.3 µs	N/A
🆕	mangler[typescript.js]	N/A	39.6 ms	N/A
🆕	minifier[antd.js]	N/A	164.4 ms	N/A
🆕	minifier[react.development.js]	N/A	1.8 ms	N/A
🆕	minifier[typescript.js]	N/A	288.8 ms	N/A
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

[Boshen]

Merge activity

• May 14, 12:46 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• May 14, 12:46 AM EDT: Boshen added this pull request to the Graphite merge queue.
• May 14, 12:57 AM EDT: Merged by the Graphite merge queue.

[camc314]

it might also be faster to use memchr_iter rather than a loop and having the searcher re-compiled again. (it also might make no difference depending on how the compiler is optimizing it)

[overlookmotel]

I don't think memchr (unlike memchr::memmem::Finder) compiles a searcher type - it's a straight function call. If it's inlined, the "needle" (@) should be statically known to compiler, which might allow it to generate more optimal code than a more complex type.

I've taken some shortcuts here - there are some bounds checks which could be eliminated, and other stuff that could be a little tighter. But my assumption was that almost all the cost is in searching for @, so everything after that was not worthwhile optimizing.

But still, yes, memchr_iter might be faster, especially if the searcher was created outside of find_jsx_pragma and passed in so it can be re-used. Want to try it?