-
Notifications
You must be signed in to change notification settings - Fork 39
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
Excessive syscalls when using BufWriter #220
Comments
Hi, sorry for the delay. Thanks for reporting this issue, it is symmetrical to the issue with Could you provide an example of something that that emits a Thanks! |
Hi, sorry for taking a while to get back to you. In the following example, the output of
Tested with |
This should increase the accuracy of positioning information in errors and ensures `stream_position` calls will only be emitted when the result may actually be used. There are still too many `stream_position` calls in part because there is no API to coordinate between parent and child objects to prevent children from doing their own position management when the parent is already doing it. Improving this will probably require some kind of rudimentary stack tracking, or at least to split the API so that `read_options` is an entrypoint and then there is e.g. `read_inner` that does not try to restore position on error. In future, it should be possible for authors to configure trading off worse error handling with performance by e.g. making error position `Option<u64>` and emitting `None`s instead of a variable reference, and giving some option to not leave the stream in a known good state on failure. Refs jam1garner#220.
This should increase the accuracy of positioning information in errors and ensures `stream_position` calls will only be emitted when the result may actually be used. There are still too many `stream_position` calls in part because there is no API to coordinate between parent and child objects to prevent children from doing their own position management when the parent is already doing it. Improving this will probably require some kind of rudimentary stack tracking, or at least to split the API so that `read_options` is an entrypoint and then there is e.g. `read_inner` that does not try to restore position on error. In future, it should be possible for authors to configure trading off worse error handling with performance by e.g. making error position `Option<u64>` and emitting `None`s instead of a variable reference, and giving some option to not leave the stream in a known good state on failure. Refs jam1garner#220.
This should increase the accuracy of positioning information in errors and ensures `stream_position` calls will only be emitted when the result may actually be used. There are still too many `stream_position` calls in part because there is no API to coordinate between parent and child objects to prevent children from doing their own position management when the parent is already doing it. Improving this will probably require some kind of rudimentary stack tracking, or at least to split the API so that `read_options` is an entrypoint and then there is e.g. `read_inner` that does not try to restore position on error. In future, it should be possible for authors to configure trading off worse error handling with performance by e.g. making error position `Option<u64>` and emitting `None`s instead of a variable reference, and giving some option to not leave the stream in a known good state on failure. Refs jam1garner#220.
I am writing to a
BufWriter<File>
. Unfortunately,std::io::BufWriter::stream_position
falls back to running aseek
syscall to figure out the current stream position. This makes my serialization workload take ~300x longer than necessary.As a workaround,
NoSeek<BufWriter<File>>
works for my usecase. In fact, the values returned bystream_position
are never used by the generated code. Emitting them only when necessary should improve the performance in many cases.The text was updated successfully, but these errors were encountered: