Code change:
assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

Related discussion:
text: I was using std::io::copy from an SSD to memory using , which reported an eye-raising 30 MB/s. Wrapping it in a BufReader (either as the outer or middle layer) made no real difference. So I googled around a bit and found the recommended size was 64KB according to some random Microsoft article, so I decided to copy-paste the std::io::copy implementation and increase the buffer size. This got up to 600 MB/s at about 256KB which sounded a lot more it continued going upwards from there past the point of believability (unless the files were being pulled from RAM as a consequence of my repeated accesses). With a 10MB Vec, I got 228.36 GB/s . Unrealistic values aside, has anybody checked the buffer value to make sure there isn't some huge low-hanging fruit for std::io::copy speeds?
You mention windows. This may be platform-specific behavior. On unix systems I would fadvise on the input file for copying. Googling tells me that the windows equivalent is . Have you tried that?
After a coarse overview, my intuition is that there is some funny business going on with the length determined by and the subsequent calls on the , that could explain the unrealistic results.
It’s possible. The actual times did increase dramatically from the std::io::copy default though - my suspicion is that there is probably some caching to RAM going on or something as cold runs were generally slower than hot runs. This was for some work code that I’m no longer actively developing. I’ll leave this email marked as unread for awhile in case I have some spare time to write a benchmark. I don’t think the other flag that was mentioned is accessible with the default open file api, but in any case it at least appears there’s some low hanging fruit wrt to std::io::copy perf
I tried benchmarking on Windoze before and after changing to (instead of the original ) and the results were slightly worse (up to ~3%) with the modified setup, both on HDD and SSD. However, I'm not sure if my benchmarks were good enough - I was having a hard time tweaking them so that I could see any difference between results for different file sizes.