Closed JonathanWilbur closed 7 months ago
from_bytes
returns a &T
, whereas pod_read_unaligned
returns a T
, so for large types it may be more performant to use from_bytes
if you don't need an owned value.
If you are immediately dereferencing the &T
returned from from_bytes
to get an owned value anyway, then pod_read_unaligned
is probably better, which I suppose could be added to the docs if it isn't already.
Yes in addition to what zachs said, read_unaligned, the underlying primitive used by pod_read_unaligned
, has much worse performance on targets where "actual" unaligned reads aren't allowed at all, such as ARM. In those situations, the "one read" has to be split up into multiple single-byte reads which are then merged within a register via bit shifting, so that no individual CPU access is ever misaligned.
Okay. Maybe this should be a separate question, but how do I make a slice aligned? I tried using from_bytes on a slice from index 0 to index sizeof
The usual way is to allocate it as the more aligned type, then convert to the less aligned type when you need to work in the less aligned type.
For example, allocate a vec of u64, then if you need it as a buffer of u16 values use cast_slice or cast_slice_mut
Okay, that makes sense. Thank you! I will close this.
Is there a performance benefit? I had a runtime failure because a slice wasn't aligned when using
from_bytes
, but it wasn't a problem when I usedpod_read_unaligned
.