Open bchavez opened 8 years ago
@bchavez While this is not officially part of the protocol specification, the current code guarantees that the "t"
field always comes first in the response object. https://github.com/rethinkdb/rethinkdb/blob/next/src/client_protocol/json.cc#L101
This isn't likely to change in the next couple versions (and will almost certainly never change in a minor release, e.g. 2.3.1 -> 2.3.2).
If you want to be extra safe, you could maybe check if the third byte is t
. If that's not the case, you can fall back to the old implementation on that connection.
Hey @danielmewes thanks very much for your guidance. This is starting to look like a very cool protocol optimization for the C# driver. :+1:
:sunny: :crescentmoon: [**"I've been counting down the days and the nights..."**_](https://www.youtube.com/watch?v=uMcYRk_o82M)
Asked on slack
#driver-dev
:Hey there... was thinking more about the performance of the C# driver... I was wondering, at the protocol level, is there assurance that the JSON response string will always have the
"t"
(Response
type) first before the response error"e"
and data"r"
properties? Example response:If so, I think I can pull off some crazy optimizations tricks by figuring out the
Response
type without actually having to parse the full JSON string. This would allow me to route the JSON response though the driver knowing it's response type to its proper destination for parsing. Might allow the use of Intel SIMD/CPU vectorization too. Check this out:So, all I'd need to do is mask bytes 5 and 6 to figure out what the response type is when I read the first
Long
bytes of the response stream. Actually, it's there already, as a compile-time constant. :smile: Let me know. Thx.