@mhdawson I ran individual benchmarks for each data type to test whether removing the validation would improve the performance to some significance, but the only data type for which this was the case was Int64. All the convert-to-native APIs have pretty much the same performance whether or not we validate.

I suspect that's because in napi_get_value_int64() we not only validate that the value we are asked to convert to native is indeed a JavaScript number, but we also perform some sanitization of the value:

  if (val->IsInt32()) {
    *result = val.As<v8::Int32>()->Value();
    return napi_clear_last_error(env);
  }

  RETURN_STATUS_IF_FALSE(env, val->IsNumber(), napi_number_expected);

  // v8::Value::IntegerValue() converts NaN, +Inf, and -Inf to INT64_MIN,
  // inconsistent with v8::Value::Int32Value() which converts those values to 0.
  // Special-case all non-finite values to match that behavior.
  double doubleValue = val.As<v8::Number>()->Value();
  if (std::isfinite(doubleValue)) {
    // Empty context: https://github.com/nodejs/node/issues/14379
    v8::Local<v8::Context> context;
    *result = val->IntegerValue(context).FromJust();
  } else {
    *result = 0;
}

the performance gain stems from reducing all this to just

    *result = val->IntegerValue(context).FromJust();

foregoing the special-casing mentioned in the comment.

So, a new, non-validating API really only makes sense for Int64:

Uh oh!

Uh oh!

optimize passing arguments from js to c #327

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions