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

Resolve performance issues with multiprocess plugin #71

Closed
divmain opened this issue Jun 23, 2016 · 6 comments
Closed

Resolve performance issues with multiprocess plugin #71

divmain opened this issue Jun 23, 2016 · 6 comments
Assignees

Comments

@divmain
Copy link
Member

divmain commented Jun 23, 2016

No description provided.

@divmain
Copy link
Member Author

divmain commented Jul 5, 2016

Related: nodejs/node#3145

Did some further digging to see where the bottlenecks were in our use case. Grabbed the AST for lodash.js (roughly 16MB JSON) and measured the full round-trip to pass over IPC to a child process and back. Also measured (de)serialization times using both JSON and `BSON.

The results:

Stringify took 2.004831594 seconds.
Parse took 0.681263825 seconds.
BSON serialize took 0.976388723 seconds.
BSON unserialize took 0.814068171 seconds.

Starting IPC...
Child received message.
IPC round-trip took 51.384239773 seconds.

@divmain
Copy link
Member Author

divmain commented Jul 5, 2016

Further measurements are warranted, especially of Babel's parse and generate, to determine whether the gains from parallelizing the tasks is worth the cost of (de)serialization. In particular, since the (de)serialization CPU burden is equally shared between the parent and child processes, we're looking at ~1s blocking operations that will interfere (to an unknown extent) with the parent's delegation of tasks to the worker pool.

@tptee
Copy link
Contributor

tptee commented Jul 5, 2016

Would something like https://github.com/dominictarr/JSONStream help? At least this way, parsing won't block and you can spread out the streaming over the parent's event loop.

@andrasq
Copy link

andrasq commented Jul 8, 2016

sending large ipc messages seems to be O(n^2) in the message length (see my comment in the related issue #3145). I've seen O(n^2) delays slip in during message reassembly, maybe worth a check.

@divmain
Copy link
Member Author

divmain commented Jul 8, 2016

Thanks @andrasq. I noticed the same thing. For now, I created a workaround using Unix sockets and BSON (de)serialization. Performance appears to scale linearly with the message size, and is likely good enough for our use case.

Stringify took 1.650871098 seconds.
Parse took 0.629973014 seconds.
BSON serialize took 0.962255679 seconds.
BSON unserialize took 0.775885246 seconds.

====== Starting Native IPC... ======
Child received message.
IPC took 50.578393824 seconds.

====== Starting BSON IPC... ======
Server bound on /tmp/interlock-ipc.sock...
Server has received connection from child process.
Child is connected to server.

Child received message.
BSON-IPC took 3.852710589 seconds.

@divmain
Copy link
Member Author

divmain commented Aug 10, 2016

Looks like the performance gains from farming out work to multiple processes is mostly cancelled out by all the serialization overhead. Going to close this for now, and pursue native extensions for performance improvements instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants