Open
Description
Users regularly come to the /r/rust subreddit looking for help when their Rust code doesn't perform as well as they expect. The second most common culprit (after debug vs release build) is doing unbuffered small reads from a file.
I'm wondering if there's anything we could do to help users catch or avert this more easily.
Activity
the8472 commentedon Sep 22, 2024
The File docs already mention it. All I can think of is a clippy lint, the list doesn't list anything relevant when I search for "buff".
Don't even have to scroll to see it in the RA hover:
Edit: there already is an open issue rust-lang/rust-clippy#1805
Mark-Simulacrum commentedon Sep 22, 2024
Perhaps a debug-assertion and/or eprintln that warns if we see repeated reads of under (say) 4kb on a File? If we had some notion of metrics or other "debugging opt-in" I could imagine gating it on that -- similar to e.g. go's support for profiling mutex contention when opting in.
the8472 commentedon Sep 22, 2024
We'd need either build-std or yet another mechanism to enable debug asserts in std. The existing one is only meant for UB checks. And it'd probbaly be bad for compile times to make all of them toggleable.
joshtriplett commentedon Sep 22, 2024
@Mark-Simulacrum I was thinking about exactly that: some way to easily support a
cargo perf-smoketest
or similar that helps people figure out why their Rust performance is a problem.Honestly, perhaps a script that ptraces their process and looks at read/write syscall sizes would suffice. The same script could also look at whether the binary was built in debug or release mode.
cuviper commentedon Sep 22, 2024
Another way to help users is to make the "right" thing easier, like:
This has an advantage over docs because auto-complete will suggest it.
joshtriplett commentedon Sep 22, 2024
That sounds like a great idea. Want to write an ACP?
programmerjake commentedon Sep 23, 2024
File
constructors that nudge people toward buffered I/O #446cuviper commentedon Sep 23, 2024
See #446.