3 ms·

> When sent over the wire, JSON and XML are typically compressed with gzip or deflate. …which probably amounts to CPU-years of wasted time and electricity, con

> When sent over the wire, JSON and XML are typically compressed with gzip or deflate. …which probably amounts to CPU-years of wasted time and electricity, considering how ubiquitous this is.

skewart 11y ago
This could make for a really interesting data visualization. There are probably lots of things we do as programmers that are insignificant in the context of our own systems, but are so culturally ubiquitous that they add up to an enormous impact globally. I wonder how even things like different application architecture would consume different amounts of power. Or,is there a side effect of shifting computation to the client side of causing more energy to be consumed from dirtier sources, if, say, data centers tend to draw from cheap and clean hydro power.
ggreer 11y ago
Even with binary protocols, compression is worthwhile. No matter your serialization format, most of the bytes transferred are going to be payload. And most of the time, that payload is going to have redundancies. Also, modern implementations of decompression algorithms are very efficient. Mobile SoCs can approach 100MB/sec for deflate. In other words: If your phone downloads 10GB of compressed data a month, it's going to use an extra 3-4 seconds of CPU time per day. That's a rounding error. In fact, it's quite possible that the radio power savings outweigh that extra CPU usage.
- ben_bai 11y ago
  The problem with compression is, it's everywhere. Sending a jpeg, over compressed http(s), throught a compressed and encrypted VPN is too much compression. Then the client may save the jpeg to a local compressed NTFS cache... This is just wasted performance, plus compressors are a common place for bugs, so this is also a security issue. Just stop adding compression to everything and think about it first, and then Mobile phones and modem lines may very well be an exception.

> When sent over the wire, JSON and XML are typically compressed with gzip or deflate. …which probably amounts to CPU-years of wasted time and electricity, considering how ubiquitous this is.

skewart 11y ago

This could make for a really interesting data visualization. There are probably lots of things we do as programmers that are insignificant in the context of our own systems, but are so culturally ubiquitous that they add up to an enormous impact globally. I wonder how even things like different application architecture would consume different amounts of power. Or,is there a side effect of shifting computation to the client side of causing more energy to be consumed from dirtier sources, if, say, data centers tend to draw from cheap and clean hydro power.

ggreer 11y ago

Even with binary protocols, compression is worthwhile. No matter your serialization format, most of the bytes transferred are going to be payload. And most of the time, that payload is going to have redundancies. Also, modern implementations of decompression algorithms are very efficient. Mobile SoCs can approach 100MB/sec for deflate. In other words: If your phone downloads 10GB of compressed data a month, it's going to use an extra 3-4 seconds of CPU time per day. That's a rounding error. In fact, it's quite possible that the radio power savings outweigh that extra CPU usage.

ben_bai 11y ago
The problem with compression is, it's everywhere. Sending a jpeg, over compressed http(s), throught a compressed and encrypted VPN is too much compression. Then the client may save the jpeg to a local compressed NTFS cache... This is just wasted performance, plus compressors are a common place for bugs, so this is also a security issue. Just stop adding compression to everything and think about it first, and then Mobile phones and modem lines may very well be an exception.