Investigate "t" Response Type Ordering for Crazy Fast Response Routing

[bchavez]

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:

{"t":1,"r":[true]}

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:

{"t":1,"r":[true]}
{byte[18]}
    [0]: 123 {
    [1]: 34  "
    [2]: 116 t
    [3]: 34  "
    [4]: 58  :
    [5]: 49  1
    [6]: 44  ,
    [7]: 34  "
2462397222020719227 (C# long, 64-bits, 8 bytes, representation)

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. 😄 Let me know. Thx.

[danielmewes]

@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.

[bchavez]

Hey @danielmewes thanks very much for your guidance. This is starting to look like a very cool protocol optimization for the C# driver. 👍

☀️ 🌙 _"I've been counting down the days and the nights..."_