-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
napi_create_string_utf8() performance issue #26437
Comments
An additional note: strings < 100 bytes in length are virtually indistinguishable. The performance decrease become somewhat noticeable around 1,000 bytes and at about 10,000 bytes is very noticeable at about 2x slower. Past 30,000 bytes the performance is around 4x slower and seems to stay at about that ratio after that -- at least up to 16 MB in size. |
Generally, your suggested patch makes sense. It should be applied for all of the One issue is that So, I would suggest to have |
Sure. I'm not that familiar with the Node.js internals so took the easiest route. I'll take a closer look now and create a pull request on which you can comment further. |
Ok. Take a look and let me know if that more closely aligns to what you were expecting? Let me know if any changes are required. |
I'm not sure what the process is for getting this fix backported to v10.x and v8.x. If it would help to have PRs created for each branch, please let me know. |
@anthony-tuininga the PRs are pulled in the other released automatically, if they have no conflict with the target branch. If there are conflicts, the releasing person is going to leave a comment that a manual backport is required. |
Ok. Thanks for the explanation! |
Improve performance creating strings using N-API by ensuring that the strings are not internalized. Added test cases for latin-1 and utf-16 strings. PR-URL: nodejs#26439 Fixes: nodejs#26437 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Improve performance creating strings using N-API by ensuring that the strings are not internalized. Added test cases for latin-1 and utf-16 strings. PR-URL: #26439 Fixes: #26437 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Improve performance creating strings using N-API by ensuring that the strings are not internalized. Added test cases for latin-1 and utf-16 strings. PR-URL: #26439 Fixes: #26437 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Improve performance creating strings using N-API by ensuring that the strings are not internalized. Added test cases for latin-1 and utf-16 strings. PR-URL: #26439 Fixes: #26437 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Improve performance creating strings using N-API by ensuring that the strings are not internalized. Added test cases for latin-1 and utf-16 strings. PR-URL: #26439 Fixes: #26437 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In working on the N-API implementation for the node-oracledb driver for Oracle Database it was discovered that the performance between the original V8/NAN implementation and the N-API implementation is dramatically different in some situations. I tracked it down to the fact that the napi_create_string_utf8() uses string type kInternalized instead of kNormal. For my example, creating strings of length 4 MB resulted in almost 4x more time required to create the string than with the original implementation. If I make the following change:
the performance becomes indistinguishable.
So, can this be patched? Or is there a particular reason for using the string type kInternalized? Since this is only particularly noticeable for large strings, the other possibility would be to check the length and only use kNormal if the length is greater than a particular size -- not sure if that would be better?
I tried creating a buffer and converting that to a string by using napi_create_buffer() and napi_coerce_to_string(). That works better but is still more than 2x slower.
The text was updated successfully, but these errors were encountered: