unpin and update memchr

[mati865]

I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by #129079

Fixes #127890

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

@bors try

[bors]

⌛ Trying commit 7cdbb59 with merge bd4ee4f...

[bors]

☀️ Try build successful - checks-actions
Build commit: bd4ee4f (bd4ee4f955dfc15696d30ae8a9f3b30b5b0bf2a1)

[rustbot]

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[tgross35]

@bors r+

[bors]

📌 Commit 7cdbb59 has been approved by tgross35

It is now in the queue for this repository.

[tgross35]

@bors rollup=never (perf and possible other windows failures)

[bors]

⌛ Testing commit 7cdbb59 with merge 9a77c3c...

[bors]

☀️ Test successful - checks-actions
Approved by: tgross35
Pushing 9a77c3c to master...

[rust-timer]

Finished benchmarking commit (9a77c3c): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	0.4%	[0.1%, 1.6%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	1.0%	[1.0%, 1.0%]	1

Max RSS (memory usage)

Results (primary 0.9%, 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)	1.8%	[1.3%, 2.3%]	2
Regressions ❌ (secondary)	4.4%	[4.4%, 4.4%]	1
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.8%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[-0.8%, 2.3%]	3

Cycles

Results (secondary -2.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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.2%, secondary 0.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)	0.2%	[0.0%, 0.7%]	20
Regressions ❌ (secondary)	0.4%	[0.1%, 0.7%]	75
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.0%, 0.7%]	20

Bootstrap: 780.704s -> 781.717s (0.13%)
Artifact size: 335.27 MiB -> 335.31 MiB (0.01%)

[tgross35]

I am a bit surprised to see any regressions here, I would have expected newer versions to perform better. @BurntSushi long shot but any idea if a slight loss of performance in some cases is expected between memchr 2.5.0 and 2.7.4?

[BurntSushi]

It depends. Sometimes improvements improve one area while slightly regressing another. The memchr crate did undergo a number of changes since 2.5.0. And see also: BurntSushi/memchr#161

AFAIK, there's no single benchmark that I'm aware of where there's a significant loss of performance for searching. Search construction may have gotten a touch slower as noted in the issue linked.

[Mark-Simulacrum]

My guess is the regressions are mostly spurious (recovered within 1-2 commits on their own, benchmarks are known for some bimodality). Marking as triaged.