Move always move the whole SmallVec object.

[gnzlbg]

A SmallVec<[f64; 100]> with a capacity() larger than 100 allocates the elements on the heap but moving the SmallVec generates a memcpy over the whole SmallVec object including the unused storage for the 100 f64 elements and not just 3*size.

This seems to be a general problem with enums but I couldn't find a rustc bug to track this, so I don't know if this is intended or even fixable. Anyhow, maybe SmallVec can workaround this behavior somehow?

[emilio]

I consider this to be a rust bug: rust-lang/rust#42763

[emilio]

The workaround is "don't move stuff much", unfortunately :(

Thanks a lot for noticing and for the report, but I don't think much can be done from this repo. Please reopen if you think otherwise though.

[gnzlbg]

I think that issue misses the problem I am talking about: when you move or copy an enum, Rust memcpys the whole enum storage independently of which variant is active. This is bad if one of the variants is much larger than the others. Passing something by move is intended to copy the objects storage. In the case of SmallVec this mean copying the enum. My point was that if the SmallVec is using the heap, this memcpy should not copy the whole enum, but only the parts of it needed to track the heap allocation (which are typically much smaller). This is an orthogonal issue to "not copying anything on move when you don't need to". If you are calling an extern function (e.g. From an external crate that the optimizer cannot see) then values, in most cases, need to be copied on move. If you can see the function and you move a value in and then out then you don't need any moves at all. Or if you know that the parent stackframe is alive during the function then you don't need moves either. So I think these are two different issues.

…

On Thu 2. Nov 2017 at 06:30, Emilio Cobos Álvarez ***@***.***> wrote: The workaround is "don't move stuff much", unfortunately :( Thanks a lot for noticing and for the report, but I don't think much can be done from this repo. Please reopen if you think otherwise though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3NpgX54U-ePplN5YNF3z7_GWC4akjmks5syVNvgaJpZM4QOJpK> .

[emilio]

Oh ok, I see what you mean, happy to reopen, though still not sure how can this be fixed on our side... Maybe it's better to fix a rust issue (too?).

I don't know how this would be fixed without introducing branches on move, which I don't think it's something you can do.

[Boscop]

@emilio Custom move constructors in Rust are possible:
https://mcyoung.xyz/2021/04/26/move-ctors/
This crate uses the approach described in that post:
https://crates.io/crates/moveit

Maybe we could have an optical feature to use this approach for SmallVec?

[emilio]

Having to wrap all your smallvec declarations in a macro seems like a no-go tbh, specially to fix a relatively minor perf issue.

[KalitaAlexey]

Is this issue related to my problem?
Using for value in values is always slower for me than for value in &values or for &value in &values.
https://github.com/KalitaAlexey/smallvec_iter