All message bodies as sent on the wire are some number of 0 bytes. Currently, we're relying on the hope that the malloc implementation we boil down to is smart enough to have a good-sized 0-buf that can be allocated via CoW, so that no actual allocations need to occur for the message bodies. It might be a good idea to double check this (or similar) is what's happening by creating a static buffer of [0u8; MAX_MESSAGE_SIZE] that would presumably end up in the executable .bss, and making message bodies slices into that static buffer, then comparing their performance and memory overhead.
All message bodies as sent on the wire are some number of 0 bytes. Currently, we're relying on the hope that the malloc implementation we boil down to is smart enough to have a good-sized 0-buf that can be allocated via CoW, so that no actual allocations need to occur for the message bodies. It might be a good idea to double check this (or similar) is what's happening by creating a static buffer of `[0u8; MAX_MESSAGE_SIZE]` that would presumably end up in the executable `.bss`, and making message bodies slices into that static buffer, then comparing their performance and memory overhead.
All message bodies as sent on the wire are some number of 0 bytes. Currently, we're relying on the hope that the malloc implementation we boil down to is smart enough to have a good-sized 0-buf that can be allocated via CoW, so that no actual allocations need to occur for the message bodies. It might be a good idea to double check this (or similar) is what's happening by creating a static buffer of
[0u8; MAX_MESSAGE_SIZE]that would presumably end up in the executable.bss, and making message bodies slices into that static buffer, then comparing their performance and memory overhead.