3 ms·

> JSON has been optimized to death; it seems like you could get the 2x gain and avoid a new format with normal optimization Either I'm experiencing a reading c

> JSON has been optimized to death; it seems like you could get the 2x gain and avoid a new format with normal optimization Either I'm experiencing a reading comprehension mishap or this is self contradictory. Where is a "2x gain" supposed to come from through "normal optimization" from after something has already been optimized "to death?" > SIMD JSON techniques Which are infeasible in key SQLite use cases.

brazzy 3y ago
> Credit to SQLite developers for adopting an extant binary JSON format, as opposed to inventing yet another one. The comment you are replying to cites a statement saying explicitly that they are not adopting the Postgres JSONB binary format, only the name and the abstract concept. The API is not compatible with Postgres either.
- topspin 3y ago
  I noted that and removed that bit prior to your reply. Points off for a.) inventing yet another binary JSON and/or b.) using the same name as an existing binary JSON.
  - chubot 3y ago
    Those 2 points are exactly what my comment said
chubot 3y ago
I just meant there are a zillion different known ways of optimizing JSON, that maybe could be applied here. But maybe they already optimized it to the degree they're willing and wanted a binary format
- topspin 3y ago
  SQLite developers aren't in the habit of making poor technical choices. This choice certainly has precedent: Oracle, MySQL, MongoDB, Postgres and others have implemented some form of binary encoding for JSON. Perhaps they know something you don't and deserve the benefit of the doubt.