4 ms·

JSON is so slow and inefficient. All that marshaling and unmarshaling is crazy. Binary formats will rise again. This comment says it best I think, "On the othe

by _wldu 6y ago

JSON is so slow and inefficient. All that marshaling and unmarshaling is crazy. Binary formats will rise again. This comment says it best I think, "On the other hand, if you only need 53 bits of your 64 bit numbers, and enjoy blowing CPU on ridiculously inefficient marshaling and unmarshaling steps, hey, [JSON parsing] is your funeral." - Source https://rachelbythebay.com/w/2019/07/21/reliability/ https://rachelbythebay.com/w/2019/07/21/reliability/

0xbadcafebee 6y ago
REST is so inefficient. All those bloated text fields. HTTP is so inefficient. All those newline-deliminated case-varying strings. Logs are so inefficient. Error codes are so much shorter and precise. Computers are here to make humans' lives easier. But it's not easier if we're forced to use tools that communicate in obscure ways we can't understand and later need translators for. If a human has to debug it, either it has to be translated into a human-language-like form, or it can just stay that way to begin with and save us the trouble of having to build translators into anything that outputs, extracts, transforms, or loads data. JSON is actually a wonderful general-purpose data format. It's somewhat simple (compared to the alternatives), it's grokable, it's ubiquitous, and you can `cat` it and not destroy your terminal. But of course it shouldn't be used for everything. Actually one of the only things I find distasteful about JSON is the lack of a version indicator to allow extending it. But maybe this was its saving grace. If "blowing CPU on JSON marshaling" is your big problem, boy, your business must be thriving.
- im3w1l 6y ago
  http2 is binary and so is systemd log.
- heleninboodler 6y ago
  I'm struggling to remember who, but I just recently saw a tech talk about microservices at scale by a fairly large company that had started adopting more efficient request/response formats because they discovered that in their tens of thousands of cores, some high single-digit percentage of all CPU cycles were spent marshaling and unmarshaling JSON.
throw0101a 6y ago
> Binary formats will rise again. ASN.1 FTW!!!!! :) Probably the most popular modern alternatives: * https://en.wikipedia.org/wiki/CBOR https://en.wikipedia.org/wiki/CBOR (RFC 8949) * https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers * https://en.wikipedia.org/wiki/MessagePack https://en.wikipedia.org/wiki/MessagePack
jillesvangurp 6y ago
Actually some parsers support bigint/bigdecimal. I've used jackson to parse json numbers into those data types in jackson. It's just not all json parsers are created equally.

by _wldu 6y ago

0xbadcafebee 6y ago

REST is so inefficient. All those bloated text fields. HTTP is so inefficient. All those newline-deliminated case-varying strings. Logs are so inefficient. Error codes are so much shorter and precise. Computers are here to make humans' lives easier. But it's not easier if we're forced to use tools that communicate in obscure ways we can't understand and later need translators for. If a human has to debug it, either it has to be translated into a human-language-like form, or it can just stay that way to begin with and save us the trouble of having to build translators into anything that outputs, extracts, transforms, or loads data. JSON is actually a wonderful general-purpose data format. It's somewhat simple (compared to the alternatives), it's grokable, it's ubiquitous, and you can `cat` it and not destroy your terminal. But of course it shouldn't be used for everything. Actually one of the only things I find distasteful about JSON is the lack of a version indicator to allow extending it. But maybe this was its saving grace. If "blowing CPU on JSON marshaling" is your big problem, boy, your business must be thriving.

im3w1l 6y ago
http2 is binary and so is systemd log.
heleninboodler 6y ago
I'm struggling to remember who, but I just recently saw a tech talk about microservices at scale by a fairly large company that had started adopting more efficient request/response formats because they discovered that in their tens of thousands of cores, some high single-digit percentage of all CPU cycles were spent marshaling and unmarshaling JSON.

throw0101a 6y ago

> Binary formats will rise again. ASN.1 FTW!!!!! :) Probably the most popular modern alternatives: * https://en.wikipedia.org/wiki/CBOR https://en.wikipedia.org/wiki/CBOR (RFC 8949) * https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers * https://en.wikipedia.org/wiki/MessagePack https://en.wikipedia.org/wiki/MessagePack

jillesvangurp 6y ago

Actually some parsers support bigint/bigdecimal. I've used jackson to parse json numbers into those data types in jackson. It's just not all json parsers are created equally.