Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lint request: unbuffered I/O usage #1805

Open
olson-dan opened this issue May 31, 2017 · 4 comments
Open

Lint request: unbuffered I/O usage #1805

olson-dan opened this issue May 31, 2017 · 4 comments
Labels
A-lint Area: New lints E-hard Call for participation: This a hard problem and requires more experience or effort to work on E-medium Call for participation: Medium difficulty level problem and requires some initial experience. L-perf Lint: Belongs in the perf lint group T-middle Type: Probably requires verifiying types

Comments

@olson-dan
Copy link

I and several other beginners have run into the surprising issue that Rust's default file reading and writing methods are unbuffered and buffered IO is purely opt-in with this language. It may be useful to add a lint to warn users about this, as it seems to come up from time to time when comparing programs to other languages such as Python.

@clarfonthey
Copy link

This shouldn't apply when methods like read_to_end or read_to_string are used, because no intermediate buffering is necessary in that case.

@olson-dan
Copy link
Author

Yes, I agree, the lint would need to indicate unbuffered IO as an issue only when there is a likely performance issue.

@oli-obk oli-obk added L-perf Lint: Belongs in the perf lint group E-hard Call for participation: This a hard problem and requires more experience or effort to work on E-medium Call for participation: Medium difficulty level problem and requires some initial experience. A-lint Area: New lints T-middle Type: Probably requires verifiying types labels May 31, 2017
@llogiq
Copy link
Contributor

llogiq commented Jun 1, 2017

The lint would trigger on all eligible Read/Write operations where self is a File/Stdin/Stdout/StdinLock/StdoutLock/TcpStream/UnixStream. Suggest wrapping self in a BufReader/BufWriter to improve performance.

Note that there will be false positives where a) the direct IO is really intentional or b) a custom buffering solution is taken. Those are unlikely to be hit by new users, and one can deactivate this lint on a case-by-case basis. The docs should reflect this.

@pickfire
Copy link
Contributor

Note that StdinLock is buffered. I will open another issue for this and it could be specifically for BufReader::new(io::stdin()).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints E-hard Call for participation: This a hard problem and requires more experience or effort to work on E-medium Call for participation: Medium difficulty level problem and requires some initial experience. L-perf Lint: Belongs in the perf lint group T-middle Type: Probably requires verifiying types
Projects
None yet
Development

No branches or pull requests

5 participants