When rpc deserializes a tuple, it cannot do so into a std::tuple constructor arguments, since argument evaluation order is unspecified but deserialization must proceed left-to-right. So we deserialize after the tuple is constructed.
However, if the tuple has zero or one elements, then there is no reordering problem. Take advantage of that and deserialize in the constructor, saving some steps.
I observed a significant reduction in text size in ScyllaDB's messaging_service.o:
text data bss dec hex filename
6797398 48 236 6797682 67b972 messaging_service.o.before
6758146 48 236 6758430 67201e messaging_service.o.after
avikivity
commented
3 weeks ago
When rpc deserializes a tuple, it cannot do so into a std::tuple constructor arguments, since argument evaluation order is unspecified but deserialization must proceed left-to-right. So we deserialize after the tuple is constructed.
However, if the tuple has zero or one elements, then there is no reordering problem. Take advantage of that and deserialize in the constructor, saving some steps.
I observed a significant reduction in text size in ScyllaDB's messaging_service.o:
text data bss dec hex filename 6797398 48 236 6797682 67b972 messaging_service.o.before 6758146 48 236 6758430 67201e messaging_service.o.after
A 40kB reduction.