4 ms·
Interesting approach! But aren't JSON arrays a pretty wasteful encoding? Since this is an opaque serialization of an instruction set, why not try to encode mor
by anonymousblip 6y ago
Interesting approach! But aren't JSON arrays a pretty wasteful encoding?
Since this is an opaque serialization of an instruction set, why not try to encode more bits per number (JSON floats support lossless integers of many more bits), and moving the "symbol table" (string data) to the end?
This way you could also compress redundant symbols into single strings.
- AaronFriel 6y agoNow that you have .TEXT and .DATA sections, you're only a few sentences away from suggesting that the compression/diff algorithm generate and send WASM's binary encoding.
- Joker_vD 6y agoWhat about BPF?
- judofyr 6y agoAuthor of the article here. The format itself is not strictly speaking coupled to JSON: https://github.com/sanity-io/mendoza/blob/master/docs/format.adoc#patch-format https://github.com/sanity-io/mendoza/blob/master/docs/format.... If you can encode int8 and string more efficiently, then you can save some bytes with a custom binary encoding. However, you always need to be able to represent JSON as well. If a part of the JSON file isn't present in the old version, then you encode that part by the plain JSON. > and moving the "symbol table" (string data) to the end? … you could also compress redundant symbols into single strings. Sounds interesting, but in my experience these types of tricks are usually not paying off compared to just sending it through Gzip afterwards.