-
Notifications
You must be signed in to change notification settings - Fork 34
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
Measure nanomsg perf after error handling implementation #57
Comments
Raw OutputAfter Error Handlingnanomsg sampsongao/node-nanomsg@df36232 node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_l at.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait real 0m9.445s real 0m9.632s real 0m9.159s real 0m9.645s real 0m9.607s Before Error handlingnanomsg sampsongao/node-nanomsg@c70c99c node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait real 0m9.819s real 0m9.638s real 0m9.554s real 0m9.789s real 0m9.465s Before napinanomsg: sampsongao/node-nanomsg@4e2bccf node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait node-6.2 perf/local_lat.js tcp://127.0.0.1:5555 1 100000& node-6.2 perf/remote_lat.js tcp://127.0.0.1:5555 1 100000 && wait real 0m9.668s real 0m9.390s real 0m9.513s real 0m9.577s real 0m9.638s |
After introduction of error handlingnanomsg sampsongao/node-nanomsg@df36232
After introduction of napinanomsg sampsongao/node-nanomsg@c70c99c
Originalnanomsg: sampsongao/node-nanomsg@4e2bccf
|
So we introduced about 24% more latency and about 5 percent regression in throughput. |
I'm not sure but does this mean it is for 1 byte messages: message size: 1 [B] ? If so we probably want data with more realistic message sizes as well (hoping its configurable) as I'd expect in real-life 1 byte messages won't necessarily be the norm. |
I might also be useful to try to find the section of code that most affects the latency so we can understand where the additional time is being added. |
for message size of 10 bytes
|
We should be able to use standard profiling tools, perf even has node.js support so I'd start with that on linux |
To understand why Latency is 30% slower with NAPI. |
Weight within napi9.55% node node [.] napi_get_value_int32 ◆ |
System InfoUbuntu 14.04.2 LTS (GNU/Linux 3.13.0-55-generic x86_64) CPU InfoArchitecture: x86_64 |
Performance update after fixing the GC from Napi::Callback #120
|
@sampsongao What was the fix? |
Also, what was the workload here? Same as before, 10 byte messages? |
This is using 1 byte message. |
Data from @sampsongao using 1 byte message size
|
Update: investigated further about the reason of this GC difference. The conclusion is that nanomsg code itself is introducing a leak by not freeing Napi::Callback allocated and thus the extra object we allocate in Napi::Callback is taking extra space. By freeing Napi::Callback, Nan implementation and Napi implementation of Callback are both ok. But not sure if we want to be different from nan in this case? So the fix is as following
Which is already resolved in original node-nanomsg repo. So my next step is to pull in update from original repo and remeasure the performance based on the most updated nanomsg code. |
Different in what way? In general we should not be too concerned with doing things exactly like nan. First, Nan is very V8-specific. Second, Nan is basically unable to make breaking changes to fix any issues in its API, because its entire purpose is to provide a more stable API. Since we are introducing an entirely new API, now is our chance to make improvements. See this comment from the Nan maintainer. |
So in Nan::Callback, it put the callback directly under the persistent value; in Napi::Callback, we have first store callback under object, and then put the object under the persistent value. Not sure if this is necessary or bringing us any improvement. |
That indirection serves no purpose as far as I can see. Note the |
Port nanomsg on their current master at napi-port-3.2.4.
|
No description provided.
The text was updated successfully, but these errors were encountered: