-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
<fstream>: Non-char types are 30 to 50x slower when reading/writing than regular char #817
Labels
Comments
StephanTLavavej
changed the title
fstream: Non-char types are 30 to 50x slower when reading/writing than regular char
<fstream>: Non-char types are 30 to 50x slower when reading/writing than regular char
May 10, 2020
The new |
@jessey-git If you add to your repro the lines:
then the performance will be the same.
|
related issue #605 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Reading and writing to ifstream/ofstream is 30 to 50x slower when using
uint8_t
orstd::byte
vs. using regularchar
.Attached is a small repro program demonstrating the poor behavior.
This caught me off guard in a project of mine where I attempted to do the "right" thing and was swiftly penalized for it. I tried to represent a buffer as a
vector<uint8_t>
rather thanvector<char>
and suddenly reading/writing that buffer became enormously slow. This was just before std::byte became available. I worked around it using reinterpret_cast<char *>Now that std::byte is well enough into the ecosystem I decided to test again to see if that's affected as well and it sure is. I can see this becoming a large issue if folks actually embrace the byte in modern, idiomatic c++.
Compiled Version 16.6.0 Preview 6.0
Machine 1:
Machine 2:
Command-line test case
Build and run the attached vs solution in x64 Release mode
Expected behavior
Equivalent performance for all similar data types
char
,uint8_t
, andstd::byte
STL version
16.6.0 Preview 6.0
SlowIO.zip
The text was updated successfully, but these errors were encountered: