Skip allocations, serialization and deserialization of request data for in-memory requests #6021
Conversation
…sing a WeakMap) The new request type is used by in-process requests. to skip the buffer allocations, serialization, and deserialization of the request data and buffers.
There was a problem hiding this comment.
@nb-ohad I am not sure about all these changes in rpc.js.
I don't want all those functions that used to take a request and operate on it to change to avoid it as it just makes the code complex.
If you just want to control the encoding, maybe we can simply move the encode/decode functions from request to the connection? Would that work?
|
@guymguym I don't really want only to control the encoding/decoding I want to eliminate the allocation of a new set of buffers + serialization and deserialization. RPC works just the way it worked before with a slight change where the class for requests is selected in run time based on the connection type. We can move the encode and decode implementation into a diff place (like a message encoder/decoder) but this will not eliminate the need of a seperate request representation Thoughts? |
|
Closing - this PR was replaced by #6027 |
Explain the changes
Add in-memory request type that holds the request data in memory
The new request type is used by in-process requests. to skip the buffer allocations, serialization, and deserialization of the request data and buffers.
Issues: Fixed #xxx / Gap #xxx
Testing Instructions: