Решил таки жить с последним вариантом и не искать сериализатор, который даст мне штуковину, как, например, у rkyv с AlignedVec, который решает эту проблему (да и альтернатив не особо видно, плюс не хочется сейчас формат сериализации менять).

Написал три бенчмарка, надеюсь нигде не протупил с black_box() и оно ничего не оптимизировало, результаты там такие:


test bench_serialize ... bench: 2,825 ns/iter (+/- 65)
test bench_deserialize ... bench: 2,385 ns/iter (+/- 56)
test bench_deserialize_unchecked ... bench: 410 ns/iter (+/- 12)
test bench_move_1 ... bench: 44 ns/iter (+/- 0)
test bench_move_2 ... bench: 44 ns/iter (+/- 1)
test bench_move_3 ... bench: 44 ns/iter (+/- 0)
test bench_move_4 ... bench: 44 ns/iter (+/- 0)
test bench_move_5 ... bench: 44 ns/iter (+/- 0)
test bench_move_6 ... bench: 44 ns/iter (+/- 0)
test bench_move_7 ... bench: 44 ns/iter (+/- 0)


Я сериализировал/десериализировал структурку с массивом из 16 элементов, в каждом из которых два 64-битных числа, строка на 32 байта, 64 случайных байта. Итого получилось примерно 2 килобайта данных.

И сделал 7 штуковин, которые эти два килобайта перемещают внутри вектора на n байт влево. Как видим — это пыль совсем. Т.е. мы можем спокойно на всякий случай префиксовать данные местом под потенциальное выравнивание, а перед тем как нам это нужно читать — проверить, и если не повезло (чего по идее вообще не будет происходить в большей части случаев), то просто сместить. Возможно на больших объёмах оно становится хуже, но скорее всего не сильно значительно, да и если будет беспокоить — тогда и посмотрим/форкнем библиотечку, сделаем эту замену вектора на вектор пачек байт, предложим PR, все дела.

#rust