4 ms·
It sounds like the approach is to set aside e.g. 11 bytes for an i32 field and write or read all 11 of them on each access, and to do similar things for strings
by anonymoushn 4y ago
It sounds like the approach is to set aside e.g. 11 bytes for an i32 field and write or read all 11 of them on each access, and to do similar things for strings, such that their lengths must be bounded up-front. It's interesting, but it requires a bit of work from the end user, and to be polite one may want to remove all the extra spaces before sending the data over the wire to a program that isn't using these techniques.
- cmrdporcupine 4y agoah, I see. I think I'd take a different approach and send along an "offset map" index blob which maps (statically known in advance based on a schema that both client and server would need to agree to) field IDs to memory offsets&lengths into a standard JSON file. Then you have a readable JSON, but also a fast way O(1) to access the fields in a zero-copy environment. Done right the blob could even fit in an HTTP response header, so standard clients could use the msg as is while 'smart' clients could use the index map for optimized access. But as I said would suffer from numeric values being text encoded. And actually 'compiling' the blob would be an extra step. Wouldn't have all the benefits of flatbuffers or capnproto, but could be an interesting compromise. I'd be surprised if this isn't already being done somewhere.
- politician 4y agoTake a look at Msgpack.
- cmrdporcupine 4y agoI have before, but that's very different from what I'm brainstorming here.
- nerpderp82 4y agoYeah, you all get it.