Description
io::Error::new
will always allocate. This isn't a huge deal when the error represents an actual error case, however I/O "errors" are used often to signal termination in hot paths and the allocation can cause significant bottleneck.
One example is with non-blocking I/O, io::ErrorKind::WouldBlock
is used to signal that the source is not read to process the op. Suffering an allocation for this very common case is not acceptable.
To work around this, Mio provide a helper to construct a WouldBlock
error without the allocation: https://github.com/carllerche/mio/blob/master/src/io.rs#L40-L49.
However, WouldBlock
is not the only case. Another common case that I am hitting is using io::ErrorKind::WriteZero
being triggered when calling write_all
to io::Write
implementations that are backed by memory (vs. an I/O type).
In general, there should be a way to construct I/O errors without allocating.
/cc @alexcrichton
Activity
arthurprs commentedon Sep 24, 2016
One option on top of my head is to provide a
from_kind
that constructs an opaque-ish error with that kind, otherwise there's alwaysfrom_raw_os_error
io:ErrorKind
toio::Error
#37037Auto merge of #37037 - Mark-Simulacrum:stack-error, r=alexcrichton
Mark-Simulacrum commentedon Nov 4, 2016
@carllerche Do you (or others) know if
std::io
should now be examined for instances whereError::new
is used in non-optimal ways?carllerche commentedon Nov 10, 2016
I haven't looked much in std. I mostly needed this for mio (https://github.com/carllerche/mio)