Couldn't find an issue for this and don't know if it counts but filing anyway.
If you have
fn foo(s: &[i8]) -> Vec<u8> {
s.iter()
.map(|&x| x as u8)
.collect()
}
the SpecExtend machinery ensures that the vector has s.len() space reserved in advance. However if you change it to return a result
fn foo(s: &[i8]) -> Result<Vec<u8>> {
s.iter()
.map(|&x| if x < 0 { Err(...) } else { Ok(x as u8) } )
.collect()
}
then (based on examining the LLVM IR and heaptracker's "Temporary" measurements) that optimization has quietly been lost.
This is technically correct in the sense that the first element yielded could be an Err of course (the size hint for the Adapter in Result's FromIterator impl has a lower bound of 0). But this pessimizes the good path to take more memory and be slower in favor of possibly saving memory on the bad one, which seems backwards.
Is there a specialization that could be added to fix this?
kennytm, Dushistov, dylni, Equim-chan, kornelski and 6 more
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4