node-api: refactor napi_set_property function for improved performance

[mertcanaltin]

Node.js PR #50282 - N-API Performance Improvement

This pull request aims to optimize the napi_set_property function to enhance the overall performance of Node-API. The changes include:

• The signature of the node_api_create_property_key_utf16 function has been updated to match the proposed format.
• The node_api_create_property_key_utf16 function is now implemented using the NewString function for a more streamlined approach.
• The napi_set_property_utf16 function, which did not provide additional advantages over node_api_create_property_key_utf16, has been removed.
• Documentation for the new APIs has been updated, and sample tests have been added.

It's worth noting that these changes are focused on improving the overall performance of Node-API operations, especially those involving property access.

/w @vmoroz 🙏
issue: #49922

[nodejs-github-bot]

Review requested:

• @nodejs/node-api

[vmoroz]

@mertcanaltin , thank you for working on the improvements to Node-API!
We have discussed your change last week in Node-API team meeting on 10/20/2023.

It seems that the change is targeting to address the same issues as we discussed them in #45905.
I do not believe that the new proposed napi_set_property_utf16 will make a significant perf improvement comparing with creating napi_value string with napi_create_string_utf16 and then using it with napi_set_property.

A better approach would be to create property keys with v8::NewStringType::kInternalized flag and then reusing them to set properties for multiple objects. V8 internally uses internalized strings for all properties. This way they can compare string pointers instead of the whole string. If we use a normal string to access properties, then V8 must internalize it first.

Would you be interested to implement such functions that create internalized strings?
They can improve speed for all property access operations: set, get, has, delete.
They are based on the this proposal: #45905 (comment)

napi_status node_api_create_property_key_latin1(napi_env env, constchar* str, size_t length, napi_value* result); napi_status node_api_create_property_key_utf8(napi_env env, constchar* str, size_t length, napi_value* result); napi_status node_api_create_property_key_utf16(napi_env env, constchar16_t* str, size_t length, napi_value* result); napi_status node_api_create_property_key(napi_env env, napi_value str_or_sym, napi_value* result);

The first three functions must create internalized strings from latin1, utf8, and utf16 strings.
The implementation must be the same as the napi_create_string_latin1, napi_create_string_utf8, and napi_create_string_utf16 except that they must use v8::NewStringType::kInternalized instead of v8::NewStringType::kNormal.

The last one must internalize napi_value string or symbol if they are not internalized yet.
I am not sure if symbols need to be internalized. We can return them "as-is" to start with.

[mertcanaltin]

@mertcanaltin , thank you for working on the improvements to Node-API! We have discussed your change last week in Node-API team meeting on 10/20/2023.

It seems that the change is targeting to address the same issues as we discussed them in #45905. I do not believe that the new proposed napi_set_property_utf16 will make a significant perf improvement comparing with creating napi_value string with napi_create_string_utf16 and then using it with napi_set_property.

A better approach would be to create property keys with v8::NewStringType::kInternalized flag and then reusing them to set properties for multiple objects. V8 internally uses internalized strings for all properties. This way they can compare string pointers instead of the whole string. If we use a normal string to access properties, then V8 must internalize it first.

Would you be interested to implement such functions that create internalized strings? They can improve speed for all property access operations: set, get, has, delete. They are based on the this proposal: #45905 (comment)

napi_status node_api_create_property_key_latin1(napi_env env, constchar* str, size_t length, napi_value* result); napi_status node_api_create_property_key_utf8(napi_env env, constchar* str, size_t length, napi_value* result); napi_status node_api_create_property_key_utf16(napi_env env, constchar16_t* str, size_t length, napi_value* result); napi_status node_api_create_property_key(napi_env env, napi_value str_or_sym, napi_value* result);

The first three functions must create internalized strings from latin1, utf8, and utf16 strings. The implementation must be the same as the napi_create_string_latin1, napi_create_string_utf8, and napi_create_string_utf16 except that they must use v8::NewStringType::kInternalized instead of v8::NewStringType::kNormal.

The last one must internalize napi_value string or symbol if they are not internalized yet. I am not sure if symbols need to be internalized. We can return them "as-is" to start with.

Thank you very much for reviewing and detailing, I will be working on it again with an update in the future

[mertcanaltin]

This commit refactors the napi_set_property_utf16 function to use internalized string property keys, which can lead to better performance. It implements @vmoroz suggestion to create internalized string property keys for accessing object properties. Internalized keys improve speed for property access operations like set, get, has, and delete by allowing V8 to compare string pointers instead of the entire string. This change aligns with the proposal in issue #45905.

New functions added:

• node_api_create_property_key_utf16 to create internalized property keys from UTF-16 strings.
• napi_set_property_utf16 now uses internalized property keys for setting object properties.

This change is expected to enhance the overall performance of Node-API operations involving property access.

Fixes: #50282

[vmoroz]

This commit refactors the napi_set_property_utf16 function to use internalized string property keys, which can lead to better performance. It implements @vmoroz suggestion to create internalized string property keys for accessing object properties. Internalized keys improve speed for property access operations like set, get, has, and delete by allowing V8 to compare string pointers instead of the entire string. This change aligns with the proposal in issue #45905.

New functions added:

• node_api_create_property_key_utf16 to create internalized property keys from UTF-16 strings.
• napi_set_property_utf16 now uses internalized property keys for setting object properties.

This change is expected to enhance the overall performance of Node-API operations involving property access.

Fixes: #50282

@mertcanaltin , thank you for starting to implement the property key creation functions!
Could you make the node_api_create_property_key_utf16 function signature to match the proposed signature? It is currently missing the length of the string. The implementation should follow the same pattern as the napi_create_string_utf16.

I believe the napi_set_property_utf16 is not needed because it does not bring any value on top of the node_api_create_property_key_utf16 function. The full power of node_api_create_property_key_utf16 is that it helps reusing created string as a key, while napi_set_property_utf16 eliminates this advantage by forcing us to lookup for the key every time.

Please have a look at the PR #48339 where we added creating external strings.
This PR must use the NewString function added in that PR which makes the implementation quite simple.
You can follow the #48339 pattern to define new string APIs, changing docs, and adding new unit tests.

[mertcanaltin]

greetings thank you very much for your suggestions, I applied it, now I think I need to add a test and update the document @vmoroz

[vmoroz]

greetings thank you very much for your suggestions, I applied it, now I think I need to add a test and update the document @vmoroz

Awesome! Could you use the NewString function introduced in PR #48339 for the implementation?
There are a number of different checks that needed to be done and they are all covered by the NewString implementation.
We just need to give it the right lambda. E.g.

napi_status NAPI_CDECL node_api_create_property_key_utf16(napi_env env, constchar16_t* str, size_t length, napi_value* result){returnv8impl::NewString(env, str, length, result, [&](v8::Isolate* isolate){returnv8::String::NewFromTwoByte(isolate, reinterpret_cast<constuint16_t*>(str), v8::NewStringType::kInternalized, static_cast<int>(length))})} 

[mertcanaltin]

greetings thank you very much for your suggestions, I applied it, now I think I need to add a test and update the document @vmoroz

Awesome! Could you use the NewString function introduced in PR #48339 for the implementation? There are a number of different checks that needed to be done and they are all covered by the NewString implementation. We just need to give it the right lambda. E.g.

napi_status NAPI_CDECL node_api_create_property_key_utf16(napi_env env, constchar16_t* str, size_t length, napi_value* result){returnv8impl::NewString(env, str, length, result, [&](v8::Isolate* isolate){returnv8::String::NewFromTwoByte(isolate, reinterpret_cast<constuint16_t*>(str), v8::NewStringType::kInternalized, static_cast<int>(length))})}

thank you for your suggestion I updated as you said @vmoroz

[vmoroz]

@mertcanaltin , perfect!
The next step is to add the function to the js_native_api.h, add a unit test, and add documentation.
Please see PR #48339 where other new string-related functions were added.

[mertcanaltin]

I made the additions as you said @vmoroz 🚀 🕺

[mertcanaltin]

I think I have a problem with the napiVersion

[vmoroz]

@mertcanaltin. it looks great!
Please follow the code pattern in PR #48339:

• All new APIs must be wrapped in #ifdef NAPI_EXPERIMENTAL
• The docs for the new APIs must use added: REPLACEME
• New test cases must be added to test_string test.

Also, please put the code for the new string APIs next to the string creation APIs added in PR #48339.

[mertcanaltin]

these steps were great I hope I succeeded I made an update @vmoroz 🚀

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56411/

[gabrielschulhof]

Why do we need to cast to int here? We don't cast to int in the regular version of this function.

[mertcanaltin]

Hello, I created this space based on the recommendation of @vmoroz, as mentioned in pull request #48339.

[vmoroz]

@gabrielschulhof , we are getting warnings in MSVC compiler if types are mismatch.
The NewFromTwoByte expects type int which is signed 32-bit integer.
In this function length is size_t which is unsigned 64-bit integer for 64 platforms.
MSVC warns about possible precision loss when the cast implicitly here.
The explicit cast suppresses the warning as we explicitly express our intent.

Ideally, we must add the cast in other places too to avoid the MSVC warnings.
But it should be another PR since currently Node.js has a lot of MSVC warnings anyway.

[mertcanaltin]

I removed my tag so as not to do something wrong, maybe the whole pipeline should go through and then I thought I should do it. 🤔

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56483/

[mertcanaltin]

I wonder if I should do an update here @vmoroz 🚀

[vmoroz]

I wonder if I should do an update here @vmoroz 🚀

@mertcanaltin , it seems that CI has some flaky tests. I see other PRs have the same issue.
We can try to rerun the tests and hope that they pass.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56612/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56633/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56688/

[mhdawson]

Landed in 59e7444

@mertcanaltin thanks for your work and patience on this one.

[mertcanaltin]

thank you very much for your support ❤️