3 ms·

If you want to optimize for minimal deserialization time, consider using FlatBuffers for serialization: https://google.github.io/flatbuffers/ https://google.git

If you want to optimize for minimal deserialization time, consider using FlatBuffers for serialization: https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/

ra-mos 5y ago
Flatbuffers have been good in a demux/parallel architecture I’ve been managing. We split single requests into ~100-500 requests — each using the same Flatbuffer object (list of items). Each sub request reads header data to pull some percentage (1/100-500) of data out of the flatbuffer it needs to process. The library is still fairly low level, and our abstraction has become complex. Still, the best performance approach we’ve been able to find.
k__ 5y ago
How do these binary protocols work in the browser? I read once, a custom library written in JS will probably never be as fast as the JSON parser shipped in browsers.
- tyingq 5y ago
  I don't see how it's possible that "look at every single byte for the unescaped balanced quote/bracket that ends the field/record" could be faster than "read the length, read the whole field in optimal buffer sizes". I suppose there's other stuff that's being done that could be suboptimal, but that's the key difference.
- inglor 5y ago
  Parsing JSON is tricky, you need to figure out the structure as you go. JavaScript implementations can reuse their JIT machinery to figure out the structure of parsed JSON (here's shapes if you're not familiar https://mathiasbynens.be/notes/shapes-ics https://mathiasbynens.be/notes/shapes-ics ) You _can_ do it outside the engine but it'd be tricky and you'd have to either write a lot of code _or_ to trick the engine to reuse the JIT machinery for your parser. Protocols with schemas are much much easier to parse efficiently so I suspect it'd be as fast in library written JS.
- secondaryacct 5y ago
  This is false, I've optimized horrendously large json parsing by simply rotating the data in a table form and using a binary serializer/deserializer (c.js provided by kdb: https://github.com/KxSystems/kdb/blob/master/c/c.js https://github.com/KxSystems/kdb/blob/master/c/c.js ). It's insanely faster to parse binary into js object without going through json at all than parsing string json, and we transformed a dumb application from slow death to "oh wow no need to optimize further, all perf problems are now fixed" simply by switching the serialization format (faster to download, faster to deserialize, faster to access). It even helps the backend to serialize faster than writing enormous ASCII strings just to talk to the browser memory structure. Dont forget these json format are just better xml and still made for humans. Machines can work well with structures closer to the memory layout, for instance sending the header once and subsequent objects in ordered attributes with separator is closer to how an object is stored and accessed by JS. I suppose a mistake we all make after years of JSON is thinking it represents objects for the browser but an object is always a byte array with an offset per attribute descriptor. So send the attribute descriptors and their type (which will describe a size too) first and then just fill.
  - ninkendo 5y ago
    > I suppose a mistake we all make after years of JSON is thinking it represents objects for the browser but an object is always a byte array with an offset per attribute descriptor. Doesn’t this depend on the language? Plenty of languages implement “objects” as a hash table underneath, with properties just being keys. In fact I think most JavaScript engines even work this way, at least until some amount of JIT optimization happens to start assigning static offsets to known keys (I believe this was one of v8’s advancements when Chrome first came out.)
  - MaxBarraclough 5y ago
    Are there any good benchmarks for deserialization performance with JSON/FlatBuffers/etc across the major JavaScript engines? I was surprised I couldn't find one with a quick search.
tjchear 5y ago
FlatBuffer sounds amazing. That said, when would one pick Protocol Buffer over FlatBuffer?
- viktorcode 5y ago
  From Flatbuffers spec: > Why not use Protocol Buffers, or .. ? Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has no optional text import/export.

If you want to optimize for minimal deserialization time, consider using FlatBuffers for serialization: https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/

ra-mos 5y ago

Flatbuffers have been good in a demux/parallel architecture I’ve been managing. We split single requests into ~100-500 requests — each using the same Flatbuffer object (list of items). Each sub request reads header data to pull some percentage (1/100-500) of data out of the flatbuffer it needs to process. The library is still fairly low level, and our abstraction has become complex. Still, the best performance approach we’ve been able to find.

k__ 5y ago

How do these binary protocols work in the browser? I read once, a custom library written in JS will probably never be as fast as the JSON parser shipped in browsers.

tyingq 5y ago
I don't see how it's possible that "look at every single byte for the unescaped balanced quote/bracket that ends the field/record" could be faster than "read the length, read the whole field in optimal buffer sizes". I suppose there's other stuff that's being done that could be suboptimal, but that's the key difference.
inglor 5y ago
Parsing JSON is tricky, you need to figure out the structure as you go. JavaScript implementations can reuse their JIT machinery to figure out the structure of parsed JSON (here's shapes if you're not familiar https://mathiasbynens.be/notes/shapes-ics https://mathiasbynens.be/notes/shapes-ics ) You _can_ do it outside the engine but it'd be tricky and you'd have to either write a lot of code _or_ to trick the engine to reuse the JIT machinery for your parser. Protocols with schemas are much much easier to parse efficiently so I suspect it'd be as fast in library written JS.
secondaryacct 5y ago
This is false, I've optimized horrendously large json parsing by simply rotating the data in a table form and using a binary serializer/deserializer (c.js provided by kdb: https://github.com/KxSystems/kdb/blob/master/c/c.js https://github.com/KxSystems/kdb/blob/master/c/c.js ). It's insanely faster to parse binary into js object without going through json at all than parsing string json, and we transformed a dumb application from slow death to "oh wow no need to optimize further, all perf problems are now fixed" simply by switching the serialization format (faster to download, faster to deserialize, faster to access). It even helps the backend to serialize faster than writing enormous ASCII strings just to talk to the browser memory structure. Dont forget these json format are just better xml and still made for humans. Machines can work well with structures closer to the memory layout, for instance sending the header once and subsequent objects in ordered attributes with separator is closer to how an object is stored and accessed by JS. I suppose a mistake we all make after years of JSON is thinking it represents objects for the browser but an object is always a byte array with an offset per attribute descriptor. So send the attribute descriptors and their type (which will describe a size too) first and then just fill.
- ninkendo 5y ago
  > I suppose a mistake we all make after years of JSON is thinking it represents objects for the browser but an object is always a byte array with an offset per attribute descriptor. Doesn’t this depend on the language? Plenty of languages implement “objects” as a hash table underneath, with properties just being keys. In fact I think most JavaScript engines even work this way, at least until some amount of JIT optimization happens to start assigning static offsets to known keys (I believe this was one of v8’s advancements when Chrome first came out.)
- MaxBarraclough 5y ago
  Are there any good benchmarks for deserialization performance with JSON/FlatBuffers/etc across the major JavaScript engines? I was surprised I couldn't find one with a quick search.

tjchear 5y ago

FlatBuffer sounds amazing. That said, when would one pick Protocol Buffer over FlatBuffer?

viktorcode 5y ago
From Flatbuffers spec: > Why not use Protocol Buffers, or .. ? Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has no optional text import/export.