-
-
Notifications
You must be signed in to change notification settings - Fork 15.8k
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
Replace stdlib write/read with send/recv #12673
Comments
I believe that we have used write/read due to what the JDK does, but JDK is handling general file descriptors (meaning files too!!) while on Netty we can benefit from being specialized |
@franz1981 yep thats a good one.. I remember reading about that as well but totally forgot to open a PR / issue:) |
I can open one, it should be 2 lines of code I suppose |
Motivation: The performance Unix write/read paths is more involved (and slower) then the specialized socket send/rcv ones. Modification: Replace Unix write/read paths with send/recv Result: Better performance for single buffer send/recv
@normanmaurer
eheh |
Motivation: The performance Unix write/read paths is more involved (and slower) then the specialized socket send/rcv ones. Modification: Replace Unix write/read paths with send/recv Result: Better performance for single buffer send/recv
See fredrikwidlund/libreactor#5 for more info;
I've verified (thanks to async-profiler using dwarf stack walking) that indeed the write/read code paths are a bit more "involved" then plain send/recv with FLAG == 0
I'll run some benchs in our labs, but the issue I've mentioned (and the super nice blog posts on https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/) is encouraging
@chrisvest @normanmaurer
The text was updated successfully, but these errors were encountered: