New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipc: use vql for uint types #167407
ipc: use vql for uint types #167407
Conversation
On the plane I was reverse-engineering ipc.ts to implement it in Rust and see if we could have a "service mode" for the CLI that we could interact with like any other vscode process. In doing so, I noticed that numbers in the protocol--which are used at least twice in the message header and ID--were encoded as JSON. I was curious what benefits we'd get from encoding them as variable-length integers instead. It makes the message shorter, as expected. Encode/decode time are very, very slightly lower. I'm not sure it's worth the extra complexity, but I have included it here for your consideration.
hm, I had unit tests passing locally 😛 if there's interest I'll circle back and fix those up |
👍 to doing this from my side. This particular byte-protocol is owned by @joaomoreno If you'd like to give it a try and optimize it too, there's a different one for the extension host here. |
Huh, I didn't realize that, I always assumed ipc.ts was the underlying transport. Do you recall why we have a different implementation there vs generic ipc? |
I don't quite remember, we kept refactoring things. I think they might have ended up in a situation where rpcProtocol.ts is built on top of ipc.ts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
On the plane I was reverse-engineering ipc.ts to implement it in Rust and see if we could have a "service mode" for the CLI that we could interact with like any other vscode process. (And maybe reuse it if we have more native processes in the future)
In doing so, I noticed that numbers in the protocol--which are used at least twice in the message header and ID--were encoded as JSON. I was curious what benefits we'd get from encoding them as variable-length integers instead.
It makes the message shorter, as expected. Encode/decode time are very, very slightly lower. I'm not sure it's worth the extra complexity, but I have included it here for your consideration.
Encode speed
Decode speed