3 ms·
>[JSON] relatively lightweight Um... no? Epoch as binary, 4 bytes. As JSON, 10 bytes. 64bit big num in binary, 8 bytes, in JSON 19 bytes. For a small example
by SlowRobotAhead 7y ago
>[JSON] relatively lightweight
Um... no? Epoch as binary, 4 bytes. As JSON, 10 bytes. 64bit big num in binary, 8 bytes, in JSON 19 bytes.
For a small example object I can think of
{
“x” : “y”
}
In binary, 5 bytes. In JSON, 9 bytes.
Now... light ENOUGH because you’re using a PC and gigs of ram and a 100mbit internet, sure. Light in terms of a microcontroller? No.
I flat out could not use JSON in any of my projects and I’m not at FAANG level.
- tracker1 7y agoseems like what you're talking about would fall under the real-time streaming category... HTTP overhead alone would outweigh the JSON differences you're talking about.
- SlowRobotAhead 7y agoDouble. That's the inefficiency you can count on with JSON over CBOR or MsgPack if you're dealing with number data or short strings. Sure, the HTTP overhead and TCP overhead under that are significant if you're transferring a single bignum. How about 10,000 of them? Even if the best case of all strings where binary gets limited by ASCII's inefficiency, "":"", is "only" 5 bytes of wasted data, but what about a million item JSON? 5 million wasted bytes does seem like it outpaces NIC then TCP then HTTP layer overhead. But uea, IDK. The claim was that JSON is lightweight, it is not. It's not as bad as XML, I'll give it that.