Skip to content
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

Engine: encode message payloads #891

Open
josephjclark opened this issue Mar 4, 2025 · 0 comments
Open

Engine: encode message payloads #891

josephjclark opened this issue Mar 4, 2025 · 0 comments

Comments

@josephjclark
Copy link
Collaborator

When the runtime event emits a payload out to the worker, there are several layers of serialisation:

  • the event is sent out of the worker thread into the child process (this may require it to be serialised to string)
  • Inside the child process, its received and presumably parsed back to t javacrcipt object
  • Then its sent out of the child process into the main process - where again it is serialised to string and deserialized
  • In the main worker thread, the event object is reparsed into a JS object and carries on.

This occurs all events - log, step complete, etc. Since the runtime is quite noisy, it means a LOT of data is getting serialized

There are two possibilities to optimize this:

  • We could use a more efficient transport. We could consider streaming JSON through a websocket across the processes (so the worker thread speaks straight to the main worker process). Alternatively there are techniques for a shared array buffer, which we should be able to more efficiently stream across (on both thread borders or just one of them?)
  • We should be able to encode all the internal events into an array buffer representation and send that across the thread borders, to be reparsed into JSON on the other side. This should cut out all the intermediate JSON parsing. No-one in the child process or worker thread knows what the message content is, but this should 't matter. We maybe wan to send like a { event: string, payload: Buffer } shape so that we can read the event name at least. But I'm not sure its neccessary

The benefit of this is reduced memory overhead while exchanging messages, and probably slightly faster execution times. Less compute time too while hosting.

@github-project-automation github-project-automation bot moved this to New Issues in v2 Mar 4, 2025
@theroinaochieng theroinaochieng moved this from New Issues to DevX Backlog in v2 Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: DevX Backlog
Development

No branches or pull requests

1 participant