You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
When the runtime event emits a payload out to the worker, there are several layers of serialisation:
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:
{ event: string, payload: Buffer }
shape so that we can read the event name at least. But I'm not sure its neccessaryThe benefit of this is reduced memory overhead while exchanging messages, and probably slightly faster execution times. Less compute time too while hosting.
The text was updated successfully, but these errors were encountered: