Hacker News Reader

Comment by bearjaws | Hacker News Reader

It's nearly irrelevant, given that I can gzip JSON and send it to literally anything built in the last 10+ years. It's so ubiquitous now that many web servers will just accept gzipped content without even exposing that fact to the back end servers. You can get all the benefits of highly compressed JSON and never have interacted with gzip.

If it could somehow produce a significant reduction with fewer CPU cycles, there may be a really niche use case, but I don't see those often.

View on HN

Oh, it is completely irrelevant! I just want a data point for my mental model of gzip performance. Specifically, I am curious if the optimizations (object tables and separator elimination) are made irrelevant by gzip's dictionary, or if they result in better compression

In my experience it should not make much or any difference.

I had devs try to "optimise" the JSON our services were returning by doing things like abbreviating field names that were repeated very often or replacing long string constants with short integers or removing formatting, and so on. When I asked them to do actual test when the service returns gzipped output and they found out that even reducing the JSON size this way by half does not make any measurable difference on the compressed stream in most cases.

I found the same re: compressed stream, however I also found that hand optimizing the decompressed JSON made for significant performance improvements on underpowered devices (e.g. some old Android phone).

Well, that's true. But if performance is more important to you, just skip it and go for binary formats that can be orders of magnitude more efficient.

In general text formats are a compromise. They are bulky and and inefficient to parse. What you get in exchange is ease of development.

If you are willing to complicate the format just to improve performance, at some point you no longer get ease of development and you should just switch to binary altogether.

Reply on news.ycombinator.com