Single-byte ASCII searcher for StrSearcherImpl(pattern.rs)

[fereidani]

This adds a fast single-byte ASCII searcher using memchr. It will be useful when the user is searching for single ASCII tokens such as \s,", ', /, \n, etc which are common usecase in many applications.

Benchmark results:

Benchmark	Current stable	ByteNeedle PR	Δ
find_1byte_str_long_nomatch	36,476	3,630	−90% (10.0×)
find_1byte_str_long_match_end	37,129	3,703	−90% (10.0×)
rfind_1byte_str_long_nomatch	35,653	3,542	−90% (10.1×)
split_1byte_str_sparse	40,289	14,555	−64% (2.8×)
find_1byte_str_short_haystack	16,970	8,140	−52% (2.1×)
find_1byte_str_early_return	16,860	10,571	−37% (1.6×)
find_str	6,265	5,630	−10%
rfind_str	5,623	5,206	−7%
find_str_worst_case	1,192	1,104	−7%
split_char_dense	39,598	37,823	−4.5%
find_char_long_match_end	3,766	3,625	−3.7%
split_1byte_str_multibyte_haystack	78,827	76,092	−3.5%
find_char_short_haystack	4,203	4,070	−3%
find_char_long_nomatch	3,726	3,629	−2.6%
split_char_sparse	13,128	12,927	−1.5%
ends_with / starts_with (×4)	272	275	+1%
rfind_char_long_nomatch	3,520	3,557	+1%
rfind_str_worst_case	27,056	27,432	+1.4%
split_char_multibyte_haystack	57,433	60,890	+6%
split_1byte_str_dense	45,841	52,936	+15%

r? joboet

[fereidani]

The benchmark part is generated by Fable 5 and reviewed/slightly edited by me. Based on the new LLM/AI guidelines, I'm not sure if we want to keep the benchmark code as is.
Please let me know what to do about it.

[panstromek]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: ce885d2 (ce885d2e21824360fc562e63bb352b8c07a05c92)
Base parent: ae45457 (ae45457594a670c59cd4d5591eaa243d9a3d44d5)

[rust-timer]

Finished benchmarking commit (ce885d2): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.9%	[-0.9%, -0.9%]	1
Improvements ✅ (secondary)	-0.6%	[-0.6%, -0.6%]	3
All ❌✅ (primary)	-0.2%	[-0.9%, 0.4%]	2

Max RSS (memory usage)

Results (primary 3.7%, secondary -0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	0.9%	[0.4%, 2.5%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-6.6%, -0.5%]	6
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Cycles

Results (primary 1.9%, secondary 1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.9%, 1.9%]	1
Regressions ❌ (secondary)	1.4%	[0.4%, 5.7%]	14
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.6%, -0.6%]	2
All ❌✅ (primary)	1.9%	[1.9%, 1.9%]	1

Binary size

Results (primary -0.0%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.1%]	12
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	6
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-1.2%, 0.1%]	13

Bootstrap: 461.168s -> 460.484s (-0.15%)
Artifact size: 398.56 MiB -> 398.51 MiB (-0.01%)

[panstromek]

I'll note the same caveat as in #160731: we probably don't use this much in the compiler so the results are not very conslusive. The results on cargo are mostly codegen scheduling change and the include-blob is probably noise, that one is bimodal and flips between two states somewhat randomly. Is there a specific reason you want to benchmark the compiler on this?