4 ms·

It’s always crazy to me that we have picked encodings for data that are human-first to send between computers. JSON is in a similar boat. Absolutely enormous am

by klysm 2y ago

It’s always crazy to me that we have picked encodings for data that are human-first to send between computers. JSON is in a similar boat. Absolutely enormous amounts of computing power are spent on serialization and deserialization. That latency is experienced everywhere too. If we used zero-copy serialization structures everywhere, a whole lot of compute would be saved

p_l 2y ago
Considerable portion of that was early ARPANET work often involving somewhat lacking access to hardware, so I'm it's formative ages internet had a lot of directly attaching teletypes to network ports. Also one can't forget about TIPs, which provided "phone modem to telnet-like" bridge service in ARPANET. Another part was how text was the one thing that people had standardise enough between different computers. FTP's ASCII and binary modes aren't about love conversion for Unix, but because "binary" meant totally different things on different hosts (could be 8bit octets, could be 28bit words, could be 36bit words, could be 60 bit, before internet fully settled down there were 40 bit hosts too). Also people are scared of compilers. All of that led to cultural bias towards textual protocols
bigbuppo 2y ago
So... what you're saying is that we should do what cobol did in 1960?
- dingdingdang 2y ago
  I tend to agree here, judiciously used json (these days often running under zstd compression) is seldomly the bottleneck on anything and allows immediate human debugging if need be.
  - hinkley 2y ago
    What we actually implement is often more constrained by what we can prototype and experiment on than how fast or how well we can define formal requirements and implement them. So much good stuff in software is down to a mix of serendipity and 'what if' and anything that reduces friction (improves ergonomics) has my vote.
  - klysm 2y ago
    Bottleneck suggests optimization for throughput. I care about latency more
pquki4 2y ago
JSON is usually used for front end-back end communication or public API endpoints, otherwise protobuf/Thrift/Avro is commonly used in the backend for internal services (that is controlled by one organization), for very good reasons. Same for HTML -- you need to thank HTML for being able to read hacker news frontpage on a 10 year old kindle with a barely usable browser. I suggest you look all these up before complaining about nothing.
- geraldwhen 2y ago
  All of those are slower than json in many contexts. JSON parsing and serialization is very fast!
  - klysm 2y ago
    In what context is json slower than protobuf?
    - vitus 2y ago
      Did you mean to ask the reverse question (in what context is protobuf slower than json)? Because that's definitely the question on my mind, since GP's assertion runs counter to my expectations and experience. JSON is a heavy-weight format that requires significantly more memory for both serialization and deserialization, and the representations of values in JSON are optimized for human consumption rather than machine consumption. Just listing a few examples: - Strings in JSON require you to scan for the terminating quotation mark that isn't escaped. Meanwhile, in protobuf, the length of the string is given to you; you can just grab the bytes directly. - Parsing an integer in JSON requires multiplication by 10 and addition / subtraction for each digit. Meanwhile, in protobuf, fixed64 and related types are either in host order or are just a ntohl away; int64 and other varint types only require bit twiddling (masks, shifts, etc). Do you think it's easier to parse "4294967296" from a string, or 5 bytes along the lines of {0x88, 0x80, 0x80, 0x80, 0x00}? - Having a format agreed-upon ahead of time (protobuf) means that your keys don't require more string parsing (JSON).
      - 2y ago
hinkley 2y ago
It's about agility (feedback loops), and enough of the problems with it as a transport mechanism can be addressed by transport encodings that we put up with the rest. Is there a similar format that is more amenable to SIMD but has similar ergonomics? That remains to be seen. But if someone makes a compelling case then I'm sure that not only could I be convinced but I could convince others. Code is meant to be read by humans, and only incidentally by computers. Transport formats are the same thing. HTTP is an even worse format than JSON, and we have really done very little to change its line format in 35 years. It's adequate to the task.
- jvanderbot 2y ago
  From the moment I understood the weakness of my encodings, it disgusted me.
- klysm 2y ago
  It not changing is not an indication of its adequacy. It’s merely an indication of backwards compatibility and lock-in effects. It’s not practical to change it even if we did have something better.
  - AgentOrange1234 2y ago
    Aren’t “all” the servers and browsers speaking in gzipped html to one another anyway? Couldn’t we do a similar kind of invisible conversion if we had some format better enough to be worthwhile?
    - klysm 2y ago
      It would be way better to use a binary representation of the structure
deleted 2y ago
[deleted]
btown 2y ago
There's a parallel universe where the right person on the Google Chrome Network Tab team (or, earlier, the Firebug team) foresaw this a decade ago, and resolved: "we will make it possible for any developer to plug in a custom binary parser in the Network Tab, able to access setup files from the project at hand, and do so in a safe and sandboxed way that's easy to deploy to colleagues." Then a billion binary formats would have bloomed. But that's not the world we ended up in.
- klysm 2y ago
  I think that’s really the difference though: tooling. That’s all you need to make it easy
akira2501 2y ago
We did that. You're welcome to use ASN.1 or some restricted subset of it if you want, and people did for quite some time, but it's brittle and inflexible nature and it's inability to be quickly edited or observed during edit-test-debug cycles deprecated it the minute we had something human readable that could reasonably replace it. In any case.. computing is entirely about serving human needs.. early computer science sort of missed the boat on that point.
intelVISA 2y ago
Most (good) orgs use zero copy binary serde in their backends, JSON is only for end users.
- 3836293648 2y ago
  Are you using serde as a general term here or are you specifically referring to the rust library? The former would make sense but I've never heard it used that way before.
  - intelVISA 2y ago
    Former, I'm too lazy to write serialization/deserialization :P
nasretdinov 2y ago
> That latency is experienced everywhere too. Don't confuse latency and bandwidth though. Most of those messages are relatively small, so they don't contribute to (network) latency almost at all. Plus gzip exists, further reducing the amount of data transmitted, thus both reducing latency and improving bandwidth utilisation. Also usually when it comes to cases where text would be actually a bottleneck (e.g. images, videos, audio, etc), binary formats are preferred and work very well, and generally you can tolerate e.g. images or audio being slightly broken, so you don't need to debug those formats too frequently. It's a nightmare do debug them though.
- klysm 2y ago
  I’m not confusing latency and bandwidth. Serialization does contribute to latency everywhere, you have to wait for the decoder or encoder. It’s another step

by klysm 2y ago

p_l 2y ago

Considerable portion of that was early ARPANET work often involving somewhat lacking access to hardware, so I'm it's formative ages internet had a lot of directly attaching teletypes to network ports. Also one can't forget about TIPs, which provided "phone modem to telnet-like" bridge service in ARPANET. Another part was how text was the one thing that people had standardise enough between different computers. FTP's ASCII and binary modes aren't about love conversion for Unix, but because "binary" meant totally different things on different hosts (could be 8bit octets, could be 28bit words, could be 36bit words, could be 60 bit, before internet fully settled down there were 40 bit hosts too). Also people are scared of compilers. All of that led to cultural bias towards textual protocols

bigbuppo 2y ago

So... what you're saying is that we should do what cobol did in 1960?

dingdingdang 2y ago
I tend to agree here, judiciously used json (these days often running under zstd compression) is seldomly the bottleneck on anything and allows immediate human debugging if need be.
- hinkley 2y ago
  What we actually implement is often more constrained by what we can prototype and experiment on than how fast or how well we can define formal requirements and implement them. So much good stuff in software is down to a mix of serendipity and 'what if' and anything that reduces friction (improves ergonomics) has my vote.
- klysm 2y ago
  Bottleneck suggests optimization for throughput. I care about latency more

pquki4 2y ago

JSON is usually used for front end-back end communication or public API endpoints, otherwise protobuf/Thrift/Avro is commonly used in the backend for internal services (that is controlled by one organization), for very good reasons. Same for HTML -- you need to thank HTML for being able to read hacker news frontpage on a 10 year old kindle with a barely usable browser. I suggest you look all these up before complaining about nothing.

geraldwhen 2y ago
All of those are slower than json in many contexts. JSON parsing and serialization is very fast!
- klysm 2y ago
  In what context is json slower than protobuf?
  - vitus 2y ago
    Did you mean to ask the reverse question (in what context is protobuf slower than json)? Because that's definitely the question on my mind, since GP's assertion runs counter to my expectations and experience. JSON is a heavy-weight format that requires significantly more memory for both serialization and deserialization, and the representations of values in JSON are optimized for human consumption rather than machine consumption. Just listing a few examples: - Strings in JSON require you to scan for the terminating quotation mark that isn't escaped. Meanwhile, in protobuf, the length of the string is given to you; you can just grab the bytes directly. - Parsing an integer in JSON requires multiplication by 10 and addition / subtraction for each digit. Meanwhile, in protobuf, fixed64 and related types are either in host order or are just a ntohl away; int64 and other varint types only require bit twiddling (masks, shifts, etc). Do you think it's easier to parse "4294967296" from a string, or 5 bytes along the lines of {0x88, 0x80, 0x80, 0x80, 0x00}? - Having a format agreed-upon ahead of time (protobuf) means that your keys don't require more string parsing (JSON).
    - 2y ago

hinkley 2y ago

It's about agility (feedback loops), and enough of the problems with it as a transport mechanism can be addressed by transport encodings that we put up with the rest. Is there a similar format that is more amenable to SIMD but has similar ergonomics? That remains to be seen. But if someone makes a compelling case then I'm sure that not only could I be convinced but I could convince others. Code is meant to be read by humans, and only incidentally by computers. Transport formats are the same thing. HTTP is an even worse format than JSON, and we have really done very little to change its line format in 35 years. It's adequate to the task.

jvanderbot 2y ago
From the moment I understood the weakness of my encodings, it disgusted me.
klysm 2y ago
It not changing is not an indication of its adequacy. It’s merely an indication of backwards compatibility and lock-in effects. It’s not practical to change it even if we did have something better.
- AgentOrange1234 2y ago
  Aren’t “all” the servers and browsers speaking in gzipped html to one another anyway? Couldn’t we do a similar kind of invisible conversion if we had some format better enough to be worthwhile?
  - klysm 2y ago
    It would be way better to use a binary representation of the structure

deleted 2y ago

[deleted]

btown 2y ago

There's a parallel universe where the right person on the Google Chrome Network Tab team (or, earlier, the Firebug team) foresaw this a decade ago, and resolved: "we will make it possible for any developer to plug in a custom binary parser in the Network Tab, able to access setup files from the project at hand, and do so in a safe and sandboxed way that's easy to deploy to colleagues." Then a billion binary formats would have bloomed. But that's not the world we ended up in.

klysm 2y ago
I think that’s really the difference though: tooling. That’s all you need to make it easy

akira2501 2y ago

We did that. You're welcome to use ASN.1 or some restricted subset of it if you want, and people did for quite some time, but it's brittle and inflexible nature and it's inability to be quickly edited or observed during edit-test-debug cycles deprecated it the minute we had something human readable that could reasonably replace it. In any case.. computing is entirely about serving human needs.. early computer science sort of missed the boat on that point.

intelVISA 2y ago

Most (good) orgs use zero copy binary serde in their backends, JSON is only for end users.

3836293648 2y ago
Are you using serde as a general term here or are you specifically referring to the rust library? The former would make sense but I've never heard it used that way before.
- intelVISA 2y ago
  Former, I'm too lazy to write serialization/deserialization :P

nasretdinov 2y ago

> That latency is experienced everywhere too. Don't confuse latency and bandwidth though. Most of those messages are relatively small, so they don't contribute to (network) latency almost at all. Plus gzip exists, further reducing the amount of data transmitted, thus both reducing latency and improving bandwidth utilisation. Also usually when it comes to cases where text would be actually a bottleneck (e.g. images, videos, audio, etc), binary formats are preferred and work very well, and generally you can tolerate e.g. images or audio being slightly broken, so you don't need to debug those formats too frequently. It's a nightmare do debug them though.

klysm 2y ago
I’m not confusing latency and bandwidth. Serialization does contribute to latency everywhere, you have to wait for the decoder or encoder. It’s another step