faster charsearcher

[bend-n]

attempt to do #141516 better
minor improvements to #82471

r? @workingjubilee

[bors]

☔ The latest upstream changes (presumably #141678) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

@bors2 @rust-timer queue

[rust-bors]

Missing command.

[mati865]

Maybe bors2 still needs try?

[workingjubilee]

er.

@bors2 try @rust-timer queue

[rust-timer]

Finished benchmarking commit (c0dc3e0): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.3%, 1.6%]	20
Regressions ❌ (secondary)	0.9%	[0.2%, 1.6%]	21
Improvements ✅ (primary)	-2.0%	[-2.1%, -2.0%]	2
Improvements ✅ (secondary)	-0.4%	[-0.5%, -0.3%]	2
All ❌✅ (primary)	0.4%	[-2.1%, 1.6%]	22

Max RSS (memory usage)

Results (primary -1.2%, secondary -1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.6%, 2.8%]	2
Regressions ❌ (secondary)	0.6%	[0.4%, 0.7%]	2
Improvements ✅ (primary)	-3.7%	[-3.9%, -3.5%]	3
Improvements ✅ (secondary)	-2.4%	[-4.4%, -0.5%]	10
All ❌✅ (primary)	-1.2%	[-3.9%, 2.8%]	5

Cycles

Results (primary -2.1%, secondary -0.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[0.5%, 2.0%]	8
Improvements ✅ (primary)	-2.1%	[-2.2%, -2.0%]	2
Improvements ✅ (secondary)	-2.0%	[-7.0%, -0.5%]	8
All ❌✅ (primary)	-2.1%	[-2.2%, -2.0%]	2

Binary size

Results (primary 0.0%, secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.2%]	19
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	39
Improvements ✅ (primary)	-0.2%	[-0.8%, -0.0%]	9
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.8%, 0.2%]	28

Bootstrap: 776.294s -> 776.026s (-0.03%)
Artifact size: 372.28 MiB -> 372.24 MiB (-0.01%)

[Noratrieb]

I ran the profile_local command that can be found in the details of the serde benchmark:

< 111,439,668  ???:
   52,308,894    rustc_resolve::rustdoc::add_doc_fragment
   50,266,584    rustc_resolve::rustdoc::unindent_doc_fragments
   26,014,579    rustc_resolve::rustdoc::prepare_to_doc_link_resolution
  -15,577,398    core::slice::memchr::memchr_aligned
    2,875,349    <core::str::pattern::CharSearcher as core::str::pattern::Searcher>::next_match
   -2,437,181    <hashbrown::raw::RawTable<(rustc_span::def_id::DefId, (rustc_middle::query::erase::Erased<[u8; 20]>, rustc_query_system::dep_graph::graph::DepNodeIndex))>>::reserve_rehash::<rustc_data_structures::sharded::table_entry<rustc_span::def_id::DefId, (rustc_middle::query::erase::Erased<[u8; 20]>, rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_span::def_id::DefId>::{closure#1}>
    2,437,151    <hashbrown::raw::RawTable<(rustc_middle::ty::Ty, (rustc_middle::query::erase::Erased<[u8; 16]>, rustc_query_system::dep_graph::graph::DepNodeIndex))>>::reserve_rehash::<rustc_data_structures::sharded::table_entry<rustc_middle::ty::Ty, (rustc_middle::query::erase::Erased<[u8; 16]>, rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_middle::ty::Ty>::{closure#1}>
   -1,455,979    __memcpy_avx_unaligned_erms
   -1,310,908    <rustdoc::html::highlight::Classifier>::advance::{closure#1}
     -709,313    __memcmp_avx2_movbe

it looks like docs processing might actually use this function (I haven't verified this) and in that case it might have gotten slower...

[workingjubilee]

@bend-n I don't know if this will be enough to run the perf queue, but at least this way you can create artifacts for a build without asking.

@bors2 delegate=try

[rust-bors]

@bend-n can now perform try builds on this pull request

[workingjubilee]

@bors2 try

[rust-bors]

⌛ Trying commit e65ed1f with merge ef13fec…

[workingjubilee]

@rust-timer queue

[rust-timer]

Finished benchmarking commit (e5df514): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.4%	[-2.8%, -1.9%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.4%	[-2.8%, -1.9%]	2

Max RSS (memory usage)

Results (primary 3.4%, secondary 0.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.4%	[2.2%, 4.6%]	2
Regressions ❌ (secondary)	2.9%	[2.7%, 3.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.6%	[-7.6%, -7.6%]	1
All ❌✅ (primary)	3.4%	[2.2%, 4.6%]	2

Cycles

Results (primary -2.0%, secondary -0.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	1
Improvements ✅ (primary)	-2.0%	[-2.3%, -1.7%]	2
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	-2.0%	[-2.3%, -1.7%]	2

Binary size

Results (primary -0.0%, secondary 0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.2%]	15
Regressions ❌ (secondary)	0.1%	[0.1%, 0.3%]	38
Improvements ✅ (primary)	-0.3%	[-1.1%, -0.0%]	6
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-0.0%	[-1.1%, 0.2%]	21

Bootstrap: 745.073s -> 746.827s (0.24%)
Artifact size: 372.30 MiB -> 372.37 MiB (0.02%)

[bend-n]

@bors2 try

more #[inline] might have significant regressions

[rust-bors]

⌛ Trying commit 99e141c with merge bd36a7c…

To cancel the try build, run the command @bors2 try cancel.

[workingjubilee]

hmm.

@rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: bd36a7c (bd36a7c3b161895c261814889d29a9d346d07b1f)

[rust-timer]

Finished benchmarking commit (bd36a7c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.3%, 1.5%]	8
Regressions ❌ (secondary)	0.7%	[0.4%, 1.6%]	5
Improvements ✅ (primary)	-0.9%	[-2.0%, -0.3%]	3
Improvements ✅ (secondary)	-0.7%	[-1.5%, -0.2%]	10
All ❌✅ (primary)	0.2%	[-2.0%, 1.5%]	11

Max RSS (memory usage)

Results (primary 1.5%, secondary 4.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.4%	[2.6%, 4.1%]	2
Regressions ❌ (secondary)	4.4%	[2.0%, 6.2%]	3
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.5%	[-2.3%, 4.1%]	3

Cycles

Results (primary -0.1%, secondary 1.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.6%, 1.6%]	1
Regressions ❌ (secondary)	1.7%	[0.7%, 2.5%]	3
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-1.7%, 1.6%]	2

Binary size

Results (primary 0.2%, secondary 0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.5%]	42
Regressions ❌ (secondary)	0.3%	[0.0%, 0.8%]	52
Improvements ✅ (primary)	-0.2%	[-0.7%, -0.0%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-0.7%, 0.5%]	46

Bootstrap: 745.447s -> 748.472s (0.41%)
Artifact size: 372.35 MiB -> 372.45 MiB (0.03%)

[bend-n]

yeah that makes sense. if i dont have the inlines, its a minor improvement of
1.6s -> 1.1s, but it doesnt actually solve the issue.

[workingjubilee]

maybe we should back out the inline(always) and trust LLVM to make the right decision once we've emitted the inline hint at all?

[bend-n]

well thats what i was checking out with commit 99e141c because otherwise it doesnt inline and still isnt nearly as good as the position based one

[bend-n]

there are minor improvements without it, but im not sure its worth doing given it doesnt fix the issue completely

[workingjubilee]

hm.

[bend-n]

your call

[workingjubilee]

Rebased, investigating properly now.

[workingjubilee]

I have added a crushingly simple benchmark modeled on the one in the original issue to make investigating this easier.

[workingjubilee]

oops. will remove that in a moment.

[workingjubilee]

So I tried adding the mentioned benchmark, and I saw the changed code was better, and so I was inclined to accept.

But then I tried adding another benchmark, matching the "ideal" case, to the binary, and the changed code got very worse. Its position in the binary was easily made less optimal by simply more code being generated.

The heavily-inlined code of the previous commit didn't have that issue, it was very close to the benchmark performance of the "ideal" case.

And to begin with it is a dubious benchmark that does not use std::hint::black_box.

Even in the worst cases, the speed differences were definitely not as bad as the initial claim in that issue.

There is no question in my mind that there are performance gains to be had here, somewhere, but I question our current approach for extracting that data. I simply do not believe in it anymore. So I cannot take this PR. We would need to first coming up with a better metric than some jank bench that wasn't based on a correct analysis to begin with.