Open naure opened 3 days ago
How much time or memory are we actually saving with the uninit shenanigans?
The proposed approach should be marginally faster than the current one thanks to postponing the padding, but this issue is more about ease of use.
Yes. I'm just curious how much we are gaining from the shenanigans currently in master compared to not doing anything special?
Do you know whether we ever did some benchmarks?
There is only the one implementation as far as I know.
This type uses
MaybeInit
with the expectation that assignment code will set values in every cell. Moreover, the matrix is usually larger than requested innew(…)
because it is padded to a power-of-two size. All in all that is error-prone and hard to debug (been there, #597).Rewrite this with a safe and easy API.
One idea is to use
Vec::with_capacity
andextend
. Another way could be based on iterators and usecollect_vec
.Regarding padding, the type should take the responsibility to fill the padding rows. It is not actually necessary to allocate that padding space. The padding can be represented with a single value to repeat, and the padding is done at the last possible time in
de_interleaving
. It could look like a methodset_padding_strategy(…)
, see the existingenum InstancePaddingStrategy
.