4 ms·

comets.json: JSON: 51949 bytes JCOF: 37480 bytes (0.721x) JSON ZIPED: 15178 bytes Zipped json wins again.

conradev 4y ago
Now I am curious – how does zipped JCOF turn out? I know that’s not the author’s intention, but I’m curious how it compresses
- bearjaws 4y ago
  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.
  - conradev 4y ago
    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
    - twawaaay 4y ago
      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.
      - dreamdeath 4y ago
        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).
        twawaaay 4y ago
        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.
- mike_hock 4y ago
  And zipped/unzipped msgpack for that matter.
  - petre 4y ago
    Precisely, I'd rather use msgpack or CBOR if it requires additional libs. I use JSON because of browser support.

Now I am curious – how does zipped JCOF turn out? I know that’s not the author’s intention, but I’m curious how it compresses

bearjaws 4y ago
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.
- conradev 4y ago
  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
  - twawaaay 4y ago
    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.
    - dreamdeath 4y ago
      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).
      - twawaaay 4y ago
        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.
mike_hock 4y ago
And zipped/unzipped msgpack for that matter.
- petre 4y ago
  Precisely, I'd rather use msgpack or CBOR if it requires additional libs. I use JSON because of browser support.