4 ms·

It's not ideal, but in practice GZIP base64 is only marginally larger than GZIP binary

• hotfix_cowboy 3y ago
  Base64 multiplies the GZIP size by 1.33x (4/3, or a 33.3% increase in size) SO (https://stackoverflow.com/questions/4715415/base64-what-is-the-worst-possible-increase-in-space-usage https://stackoverflow.com/questions/4715415/base64-what-is-t...)
  • tornato7 3y ago
    That's for Base64-encoded GZIP, not GZIP-encoded Base64 :)
• nine_k 3y ago
  Have you tried zstd, now widely supported?
• klabb3 3y ago
  Indeed, good point, and worth clarifying. A lot of people think the size overhead is the problem, which usually it isn't, like you say, because of fairly cheap compression. However, the main issue with big base64 blobs is that you can and should never assume that JSON parsers are streaming. So you may need to load the whole thing in memory, which of course isn't good. Note that I'm not necessarily blaming JSON for this. My gut feeling is that crusading for streaming parsers is a Bad Idea. Instead, this is something that should probably be a higher-level protocol, either by streaming chunks (a la gRPC) or by having separate logical data streams (see e.g. QUIC). JSON RPC does not, afaict, solve these issues.