So far, the message was parsed three times:
1) To determine if it is a request/response/event (->Type) 2) To determine the command (->Command/Event/Success) to determine the
right ctor
3) A final pass with the right ctor
Steps 1+2 can be combined into a single step by using a union type of the fields that are required to determine the right ctor. This PR does exactly that. It combines steps 1+2 so that the message needs to be parsed only once to determine the ctor.
The final parsing step (3) with the right ctor can of course not be elided. So the number of parsing operations is reduced from 3 to 2. This is a big win, because JSON parsing is slow, especially for large messages.
So far, the message was parsed three times: 1) To determine if it is a request/response/event (->Type) 2) To determine the command (->Command/Event/Success) to determine the right ctor 3) A final pass with the right ctor
Steps 1+2 can be combined into a single step by using a union type of the fields that are required to determine the right ctor. This PR does exactly that. It combines steps 1+2 so that the message needs to be parsed only once to determine the ctor. The final parsing step (3) with the right ctor can of course not be elided. So the number of parsing operations is reduced from 3 to 2. This is a big win, because JSON parsing is slow, especially for large messages.