perf(compilation): Directly construct Take and Chain

[bushrat011899]

Objective

Performance regression in compilation discovered found here was narrowed down to the movement of utility types from std::io to core::io here. Likely culprit is the introduction of core::io::take and core::io::chain to construction Take and Chain within Read::take and Read::chain. If this does not address the compilation difference, then it must be the unchanged methods which are not #[inline], such as Chain::into_inner, etc.

Have not replicated the compilation performance difference locally, happy to amend/delete this PR if a perf-run shows it has no effect.,

---

Notes

• No AI tooling of any kind was used during the creation of this PR.

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, scottmcm

[lqd]

@bors try @rust-timer queue

[scottmcm]

I'm leaving libs reviews.
@rustbot reroll

[rust-bors]

☀️ Try build successful (CI)
Build commit: d6321e3 (d6321e37d7da8ed036012cfd642e17747ffc50f2, parent: a31c27a887b40df16ab9dfb8c9f7924636092509)

[rust-timer]

Finished benchmarking commit (d6321e3): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

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

Max RSS (memory usage)

Results (secondary -3.6%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.6%	[-4.7%, -2.4%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 2.8%, secondary 3.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.8%	[2.8%, 2.8%]	1
Regressions ❌ (secondary)	3.6%	[3.6%, 3.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.8%	[2.8%, 2.8%]	1

Binary size

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

Bootstrap: 510.693s -> 511.061s (0.07%)
Artifact size: 400.56 MiB -> 402.57 MiB (0.50%)

[bushrat011899]

Very interesting, the performance results imply the regression in compilation time comes from the methods which were not modified by my PR, only moved from std to core. Since that's the case, I'm closing this PR.