[quotemstr]

Generating code per message might not be the right choice anyway: if you have a lot of messages, a table driven approach can save you a lot of code size. Optimizing for speed in microbenchmarks can lead one to pessimize overall program architecture in ways that are hard to undo later.

[jeroenhd]

It depends on your application, but if it's just generated code then I don't really see the problem with code size. As long as it's easy to (de)serialize data or add a nice big facade between the generated code and business logic, the generated backing code can be a complete mess of spaghetti code for all I care.

[dolmen]

Size of generated code matters when the target is WASM to run in browsers.

[londons_explore]

But only if you have a lot of message formats...

Generally, message specifications are written by hand, so even a big project may only have a couple of hundred. Doesn't sound so bad.

Also, presumably, if code size really is a big concern, you can decode this in more code efficient ways too, as long as you are less concerned with performance.

[quotemstr]

You might be surprised to see how quickly mechanically-generated marshaling code adds up. Look at Android's frameworks.jar one day and see how much is just the same AIDL-generated Parcel-manipulation code over and over again. Cache effects and IO costs are so severe in modern computing that my default (but rebuttable!) position is to prefer table-driven approaches over code generation wherever possible.

Windows COM switched from codegen to table-driven "stubless" marshaling decades ago at no noticeable cost to performance and with a huge code size win.