If you want to optimize for minimal deserialization time, consider using FlatBuffers for serialization: https://google.github.io/flatbuffers/
The library is still fairly low level, and our abstraction has become complex. Still, the best performance approach we’ve been able to find.
I read once, a custom library written in JS will probably never be as fast as the JSON parser shipped in browsers.
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.
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.
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.)
I was surprised I couldn't find one with a quick search.
I suppose there's other stuff that's being done that could be suboptimal, but that's the key difference.
> 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.