Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
refactor: use v8 serialization for ipc #20214
Description of Change
This changes IPC communication to use v8's Structured Clone algorithm instead of using the
This brings about a 2x performance boost for large buffers and complex objects. Latency for small messages is not significantly affected.
User-observable differences from the existing IPC API:
Notes: IPC between main and renderer processes now uses the Structured Clone Algorithm.
I did some preliminary performance testing. The numbers below are the average time taken, in milliseconds, to send a Uint8Array buffer of a given size, across 200 calls to
With the existing mojo-based
With this PR, using v8's ValueSerializer:
So this seems to be a little less than twice as fast for this use case.
Tried this with some larger buffers:
@jkleinsc I'd like to first try to find a way we can make this at least more compatible with the existing structure, if not 1:1. If we can find a way that works for 99% of use cases, then I think we should cut over directly and accept the breakage. If we find fundamental issues that are not paper-over-able, then we should investigate ways we can expose this functionality differently (perhaps a new set of APIs like
I also tried this with complex objects. The numbers below are for NxM objects, where N is the breadth and M is the depth. For example, a 2x3 object is:
A NaN represents a renderer crash.
So, quite a bit faster. I think the crashes are when constructing those stupidly large objects, rather than serializing them. And the new code does succeed on the 8x8 case, where the old code crashed.
For anyone else interested, these changes have landed in nightly - https://github.com/electron/nightlies/releases/tag/v8.0.0-nightly.20191009