4 ms·

i wonder what % of cpu cycles on AWS are spent encoding and decoding JSON.

hhh 5y ago
I wonder what % are just idle.
throitallaway 5y ago
Actually, this is horrifying to think about. I'll concede that JSON is the answer for most public HTTP APIs, but it's also used for tons of internal IPC. The energy that could be saved with more efficient alternatives is likely substantial.
- _0w8t 5y ago
  While sending data between C++/Go/Java processes as JSON is a waste, when one part is a scripting language, JSON can be more efficient than alternatives. Recently I benchmarked extension API in Chromium. Those can send arbitrary data from C++ main browser process to the renderer process running extension JS code. Internally API use a binary format plus they verify that the data matches API scheme. It turned that for complex data writing the data to JSON on C++ side, sending the string using the same API and decoding that in JS was faster. The code to read binary data and convert that to JS plus the scheme verification was not optimized in Chromium, while JSON decoder was.
- jjtheblunt 5y ago
  > is the answer i suspect you mean pragmatically for humans, since there is support for it in most libraries. but for concise equivalent marshalling, i wonder if YAML or TOML etc would be faster to parse. Or Amazon's Ion superset of JSON.
nijave 5y ago
I think a lot of the older APIs return XML and the SDKs abstract all that away. I imagine that uses even more
- Cthulhu_ 5y ago
  XML is an interesting one; on the one side it's as inefficient as JSON due to encoding data to a text format and back again, but on the other because it's more formalized it allows transfer methods like EXI [0] to turn it into a highly efficient binary interchange protocol. In theory. This technology probably came in too little too late though, since by then JSON was starting to take over. [0] https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/
staticassertion 5y ago
Or running JVM GC. Or on pointer chasing. etc. Most code is just not well optimizesd.
jasonwatkinspdx 5y ago
(De)Serialization costs definitely add up. I've seen measurements where it was 20% of cpu cycles. Even worse lots of systems out there that could get an immediate boost just by swapping libraries.

hhh 5y ago

I wonder what % are just idle.

Actually, this is horrifying to think about. I'll concede that JSON is the answer for most public HTTP APIs, but it's also used for tons of internal IPC. The energy that could be saved with more efficient alternatives is likely substantial.

_0w8t 5y ago
While sending data between C++/Go/Java processes as JSON is a waste, when one part is a scripting language, JSON can be more efficient than alternatives. Recently I benchmarked extension API in Chromium. Those can send arbitrary data from C++ main browser process to the renderer process running extension JS code. Internally API use a binary format plus they verify that the data matches API scheme. It turned that for complex data writing the data to JSON on C++ side, sending the string using the same API and decoding that in JS was faster. The code to read binary data and convert that to JS plus the scheme verification was not optimized in Chromium, while JSON decoder was.
jjtheblunt 5y ago
> is the answer i suspect you mean pragmatically for humans, since there is support for it in most libraries. but for concise equivalent marshalling, i wonder if YAML or TOML etc would be faster to parse. Or Amazon's Ion superset of JSON.

nijave 5y ago

I think a lot of the older APIs return XML and the SDKs abstract all that away. I imagine that uses even more

Cthulhu_ 5y ago
XML is an interesting one; on the one side it's as inefficient as JSON due to encoding data to a text format and back again, but on the other because it's more formalized it allows transfer methods like EXI [0] to turn it into a highly efficient binary interchange protocol. In theory. This technology probably came in too little too late though, since by then JSON was starting to take over. [0] https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/

staticassertion 5y ago

Or running JVM GC. Or on pointer chasing. etc. Most code is just not well optimizesd.

jasonwatkinspdx 5y ago

(De)Serialization costs definitely add up. I've seen measurements where it was 20% of cpu cycles. Even worse lots of systems out there that could get an immediate boost just by swapping libraries.