4 ms·
Hmm, since the Fuchsia IDL is for IPC how would the two programs communicating know what field the other chose to omit? They'd need to encode present/absent fo
by kjeetgill 5y ago
Hmm, since the Fuchsia IDL is for IPC how would the two programs communicating know what field the other chose to omit?
They'd need to encode present/absent for every single field? Too many optional fields and you end up encoding variable lengths over and over too.
They go through great lengths to define alignment, how address space specific pointers are meant to be encoded/decoded in-place, field ordering etc. They seem like opposite ends of the tradeoff spectrum to me.
Protobufs drifted towards maximizing optionals, this seems geared towards minimizing them.
- londons_explore 5y agoYou'd have optimisation that happened at the 'connect' phase, which analyzed both binaries, and metadata left by the compiler in each, and optimized the machine code by stripping out unused fields and all the code to generate them. It could also 'inline' some IPC calls by moving server code to the client.
- pjmlp 5y agoHow do expect to ever manage to do that if server and client aren't even guaranteed to be the same language? COM is one of the most battle tested IPC in production, with support for in-process shared libraries, and Microsoft never was crazy enough to try such optimizations on the Windows dynamic linker when loading COM libraries.
- kjeetgill 5y agoThat's a really cool concept I hadn't considered. But ... Too futuristic maybe? I think this operates somewhat closer to a syscall/ABI than a calling convention/FFI than you'd expect.
- richardfey 5y agoI don't think this is a valid optimisation problem: look at how the zero value is optimised away in most serialisation formats (proto, rencode, etc). It will use very few bits of information.