4 ms·
Neat. I see a lot of mention of Twitter but the first thing I thought of was packet compression. A ~50 byte packet shaves off around 20 bytes with this. Those a
by supernintendo 9y ago
Neat. I see a lot of mention of Twitter but the first thing I thought of was packet compression. A ~50 byte packet shaves off around 20 bytes with this. Those are good savings although I haven't looked into the encoder / decoder enough to know if it's worth the tradeoff of having to translate every packet on both ends. I can also see UDP datagrams being a pain in the ass to work with when you're throwing around streams of Unicode characters.
Overall though, I like it and look forward to Base131072 being possible!
- jeremyjh 9y agoI didn't see any efficiencies that exceeded 100%. Are you counting code points rather than bytes in the unicode output size? The code points still have to be serialized as bytes after that is done, but since Twitter limits you by the number of characters, not the number of bytes, this amounts to a sort of compression of data into Twitter. On the wire it would still be an expansion of course.
- piaste 9y agoFor raw packets obviously not, but if: - you're sending big byte arrays over json/xml - you cannot switch to a more efficient medium - (but you can make your remote counterpart adopt a different encoding) - and you still need to maximize your throughput then I guess you might consider base85 for utf-8 or base32k for utf-16?
- jbg_ 9y agoJSON is UTF-8 by definition, so at best you'd be using a format that looked similar.
- supernintendo 9y agoOh yeah, good point (and one that I should have thought of before posting my comment). The scenario I described would actually be less efficient.