-
Notifications
You must be signed in to change notification settings - Fork 29.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
Node-API performance #49922
Comments
Also this should probably use an Line 295 in 3838b57
PS (sorry it already is |
At least with V8, it doesn't matter if you pass in UTF-16, it'll convert it to latin1 / one-byte if possible. The way it checks that is actually pretty expensive so you're probably worse off ceteris paribus. A version of napi_set_named_property that takes latin1 is a better bet. That way at least you avoid UTF-8 decoding overhead. Aside: memcpy is a legal way of doing type punning in C++ (for POD types anyway.) |
Yes, I confirm. There is no way to pass pre-encoded UTF16 data to V8? Answer: |
Could this be a solution? I tried to do something #50282 |
This issue seems to be related to the issue #45905 where we looked at different ways to improve the perf for object creation. To improve property access we must add APIs to create internalized strings which V8 can use directly without any additional preprocessing. |
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the
never-stale
|
What is the problem this feature will solve?
Improve performance when creating large V8 objects which is critical since these must always be created on the main thread, blocking the event loop.
Currently, the overhead of each method is very significant - especially for the primitive operations such as simply setting a property.
As a very typical example of the current problem, you can consider these two methods for setting a property on an object:
Naively, one expects that using the first one will be faster when the
key
is already UTF-16. However calling this method requires to first callnapi_create_string_utf16
and the combined overhead of the two calls offsets the single call of the second method when the key is not very long (which is usually the case).What is the feature you are proposing to solve the problem?
Step 1:(not needed, see below)napi_set_named_property
that takes UTF-16Step 2: Methods that can create in one call a whole array/object from a C data structure -
especially ones for strings already encoded in UTF-16What alternatives have you considered?
No response
The text was updated successfully, but these errors were encountered: