Specialize `Bytes` on `StdinLock<'_>` by AldanTanneo · Pull Request #120053 · rust-lang/rust

@AldanTanneo

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Jan 17, 2024

@AldanTanneo AldanTanneo changed the title specialize Bytes on StdinLock<'_> Specialize Bytes on StdinLock<'_>

Jan 18, 2024

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jan 25, 2024

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Jan 26, 2024
…ytes, r=the8472

Specialize `Bytes` on `StdinLock<'_>`

I noticed recently, while profiling a little project, that I was spending a lot of time reading from stdin (even with locking). I was using the `.bytes()` iterator adaptor; I figured, since `StdinLock` is a `BufReader` internally, it would work just as fast. But this is not the case, as `Bytes` is only specialized for the raw `BufReader`, and not the `StdinLock`/`MutexGuard` wrapper. Performance improved significantly when I wrapped the lock in a new `BufReader`, but I was still a bit sore about the double buffer indirection.

This PR attempts to specialize it, by simply calling the already specialized implementation on `BufReader`.

This was referenced

Jan 26, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

Jan 26, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#107464 (Add `str::Lines::remainder`)
 - rust-lang#118803 (Add the `min_exhaustive_patterns` feature gate)
 - rust-lang#119466 (Initial implementation of `str::from_raw_parts[_mut]`)
 - rust-lang#120053 (Specialize `Bytes` on `StdinLock<'_>`)
 - rust-lang#120124 (Split assembly tests for ELF and MachO)
 - rust-lang#120204 (Builtin macros effectively have implicit #[collapse_debuginfo(yes)])
 - rust-lang#120322 (Don't manually resolve async closures in `rustc_resolve`)
 - rust-lang#120356 (Fix broken markdown in csky-unknown-linux-gnuabiv2.md)

r? `@ghost`
`@rustbot` modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Jan 26, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#107464 (Add `str::Lines::remainder`)
 - rust-lang#118803 (Add the `min_exhaustive_patterns` feature gate)
 - rust-lang#119466 (Initial implementation of `str::from_raw_parts[_mut]`)
 - rust-lang#120053 (Specialize `Bytes` on `StdinLock<'_>`)
 - rust-lang#120124 (Split assembly tests for ELF and MachO)
 - rust-lang#120204 (Builtin macros effectively have implicit #[collapse_debuginfo(yes)])
 - rust-lang#120322 (Don't manually resolve async closures in `rustc_resolve`)
 - rust-lang#120356 (Fix broken markdown in csky-unknown-linux-gnuabiv2.md)

r? `@ghost`
`@rustbot` modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Jan 26, 2024
Rollup merge of rust-lang#120053 - AldanTanneo:specialize-stdinlock-bytes, r=the8472

Specialize `Bytes` on `StdinLock<'_>`

I noticed recently, while profiling a little project, that I was spending a lot of time reading from stdin (even with locking). I was using the `.bytes()` iterator adaptor; I figured, since `StdinLock` is a `BufReader` internally, it would work just as fast. But this is not the case, as `Bytes` is only specialized for the raw `BufReader`, and not the `StdinLock`/`MutexGuard` wrapper. Performance improved significantly when I wrapped the lock in a new `BufReader`, but I was still a bit sore about the double buffer indirection.

This PR attempts to specialize it, by simply calling the already specialized implementation on `BufReader`.