lib: improve error creation performance #24747

BridgeAR · 2018-11-30T13:47:06Z

In case of an error where we only care about a cleaned up stack
trace it is cheaper to reset the stack trace limit for the error
that is created. That way the stack frames do not have to be
computed twice.
In a local mini benchmark it reduced the Error creation time by around
30 %.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

In case of an error where we only care about a cleaned up stack trace it is cheaper to reset the stack trace limit for the error that is created. That way the stack frames do not have to be computed twice.

nodejs-github-bot · 2018-11-30T13:47:07Z

@BridgeAR build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1741/pipeline

addaleax

Would it make sense to abstract this into a helper function?

lib/_http_outgoing.js

targos · 2018-11-30T14:16:41Z

Do you think V8 could help with this?

Co-Authored-By: BridgeAR <ruben@bridgewater.de>

BridgeAR · 2018-11-30T15:05:45Z

@addaleax

Would it make sense to abstract this into a helper function?

I thought about that and the reason why I did not yet do that is that we have very different signatures and we can prevent resetting the numbers in some cases. If we use this pattern more commonly, we could write something like this:

function assertSize(size) {
  errors.removeFramesFrom(assertSize);

  if (typeof size !== 'number') {
    throw new ERR_INVALID_ARG_TYPE('size', 'number', size);
  }
  if (size < 0 || size > kMaxLength) {
    throw new ERR_INVALID_OPT_VALUE.RangeError('size', size);
  }
  errors.resetFrames();
}

That way the internal errors could take care of it.

@targos

Do you think V8 could help with this?

I spoke with @hashseed about this but so far there was no real conclusion (but two issues). I personally would love to get a completely new API that would allow to reduce the code overhead and potentially allow further optimizations in V8.

Example API

function assertSize(size) {
  let err = null;

  if (typeof size !== 'number') {
    err = new ERR_INVALID_ARG_TYPE('size', 'number', size);
  } else if (size < 0 || size > kMaxLength) {
    err = new ERR_INVALID_OPT_VALUE.RangeError('size', size);
  }

  if (err !== null) {
    Error.captureStackTrace(err, assertSize);
    throw err;
  }
}

// If this would instead be written similar to: 

function assertSize(size) {
  Error.dontSetLowerStackFrames();

  if (typeof size !== 'number') {
    throw new ERR_INVALID_ARG_TYPE('size', 'number', size);
  } else if (size < 0 || size > kMaxLength) {
    throw new ERR_INVALID_OPT_VALUE.RangeError('size', size);
  }
}

jdalton · 2018-11-30T21:20:21Z

lib/internal/errors.js

  // Pass the message to the constructor instead of setting it on the object
  // to make sure it is the same as the one created in C++
  // eslint-disable-next-line no-restricted-syntax
  const err = new Error(message);
+  Error.stackTraceLimit = tmpLimit;


This seems like something V8 folks should be made aware of since, in this case, the lazily populated .stack isn't even being accessed yet. The fact that setting the Error.stackTraceLimit to 0 appears to improves basic error creation performance when the .stack isn't accessed is counterintuitive at least.

I'd rather this be tracked as a V8 issue and fixed there than throwing Error.stackTraceLimit = 0 all over the Node codebase.

As mentioned above, I already did that :)

Yes, but the V8 issues mentioned above

8451 – loading Error.stackTraceLimit could be done faster:

We load Error.stackTraceLimit every time we collect a stack trace. Maybe this is something we want to improve? See https://docs.google.com/document/d/1wwigvXVQ-mdLmSfNnLie2xVQGCt-6AKhP1OuyE38Vw8/edit

8452 – Faster stack traces:

Stack traces are not used a lot in benchmarks, but often on real web sites for telemetry purposes. Some Node.js frameworks also use it to implement async stack traces. We could use better performance for stack trace collection in general

don't clearly state this specific case though.

I opened another issue to properly address this: https://bugs.chromium.org/p/v8/issues/detail?id=8555

jdalton

I'd like to hold off on this PR. If, once the issue has been properly raised with the V8 team, there is no movement then this PR can progress as a kind of last resort.

Fishrock123

This seems reasonable to me.

I think V8 was supposed to make stacktrace gathering faster but, who knows when.

We could add some // on V8 version comments I guess

BridgeAR · 2018-12-02T14:32:52Z

I also doubt that stack traces will be fast soon. As soon as that's done, removing these should not be an issue.

I do not have a strong opinion about this PR as it's only about error cases but I don't think that adding this hurts in any way.

What I could try is to implement my suggestion (#24747 (comment)) instead as it's cleaner code, if requested.

jdalton · 2018-12-02T16:01:56Z

Just in case it got lost in the replies, my comment #24747 (comment) has not been addressed.

hashseed · 2018-12-02T16:03:47Z

I also doubt that stack traces will be fast soon.

Can confirm. We have plans, but won't be able to do any time soon.

BridgeAR · 2018-12-06T18:22:54Z

Ping @jdalton

ok

BridgeAR · 2018-12-08T14:07:50Z

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

Trott · 2018-12-08T21:28:21Z

Given the failures of test-cli-syntax on multiple hosts, I'm going to do a Rebuild rather than a Resume CI so it rebases and gets a recent commit that hopefully makes that failure less frequent:

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

Trott · 2018-12-09T00:53:51Z

Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/19340/ ✔️

Trott · 2018-12-09T02:08:07Z

Landed in a1a5c04

In case of an error where we only care about a cleaned up stack trace it is cheaper to reset the stack trace limit for the error that is created. That way the stack frames do not have to be computed twice. PR-URL: nodejs#24747 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

In case of an error where we only care about a cleaned up stack trace it is cheaper to reset the stack trace limit for the error that is created. That way the stack frames do not have to be computed twice. PR-URL: #24747 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

In case of an error where we only care about a cleaned up stack trace it is cheaper to reset the stack trace limit for the error that is created. That way the stack frames do not have to be computed twice. PR-URL: nodejs#24747 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

lib: improve error creation performance

f0ac334

In case of an error where we only care about a cleaned up stack trace it is cheaper to reset the stack trace limit for the error that is created. That way the stack frames do not have to be computed twice.

nodejs-github-bot added errors Issues and PRs related to JavaScript errors originated in Node.js core. fs Issues and PRs related to the fs subsystem / file system. http Issues or PRs related to the http subsystem. process Issues and PRs related to the process subsystem. labels Nov 30, 2018

addaleax approved these changes Nov 30, 2018

View reviewed changes

targos reviewed Nov 30, 2018

View reviewed changes

lib/_http_outgoing.js Outdated Show resolved Hide resolved

fixup: fix typo

e006df4

Co-Authored-By: BridgeAR <ruben@bridgewater.de>

jdalton reviewed Nov 30, 2018

View reviewed changes

jdalton previously requested changes Nov 30, 2018

View reviewed changes

Fishrock123 approved these changes Dec 1, 2018

View reviewed changes

BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 8, 2018

Trott closed this Dec 9, 2018

BethGriggs mentioned this pull request Dec 18, 2018

V11.5.0 proposal #25102

Merged

beevelop mentioned this pull request Dec 18, 2018

2018-12-18 Version 11.5.0 (Current) @BethGriggs beevelop/docker-android-nodejs#272

Closed

BridgeAR added the performance Issues and PRs related to the performance of Node.js. label Dec 23, 2018

BethGriggs added the backport-requested-v10.x label Jul 2, 2019

BridgeAR deleted the faster-errors branch January 20, 2020 11:43

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lib: improve error creation performance #24747

lib: improve error creation performance #24747

BridgeAR commented Nov 30, 2018

nodejs-github-bot commented Nov 30, 2018

addaleax left a comment

targos commented Nov 30, 2018

BridgeAR commented Nov 30, 2018

jdalton Nov 30, 2018 •

edited

Loading

BridgeAR Nov 30, 2018

jdalton Nov 30, 2018

BridgeAR Dec 5, 2018

jdalton left a comment

Fishrock123 left a comment

BridgeAR commented Dec 2, 2018

jdalton commented Dec 2, 2018

hashseed commented Dec 2, 2018

BridgeAR commented Dec 6, 2018

BridgeAR commented Dec 8, 2018

Trott commented Dec 8, 2018

Trott commented Dec 9, 2018 •

edited

Loading

Trott commented Dec 9, 2018

lib: improve error creation performance #24747

lib: improve error creation performance #24747

Conversation

BridgeAR commented Nov 30, 2018

Checklist

nodejs-github-bot commented Nov 30, 2018

addaleax left a comment

Choose a reason for hiding this comment

targos commented Nov 30, 2018

BridgeAR commented Nov 30, 2018

jdalton Nov 30, 2018 • edited Loading

Choose a reason for hiding this comment

BridgeAR Nov 30, 2018

Choose a reason for hiding this comment

jdalton Nov 30, 2018

Choose a reason for hiding this comment

BridgeAR Dec 5, 2018

Choose a reason for hiding this comment

jdalton left a comment

Choose a reason for hiding this comment

Fishrock123 left a comment

Choose a reason for hiding this comment

BridgeAR commented Dec 2, 2018

jdalton commented Dec 2, 2018

hashseed commented Dec 2, 2018

BridgeAR commented Dec 6, 2018

BridgeAR commented Dec 8, 2018

Trott commented Dec 8, 2018

Trott commented Dec 9, 2018 • edited Loading

Trott commented Dec 9, 2018

jdalton Nov 30, 2018 •

edited

Loading

Trott commented Dec 9, 2018 •

edited

Loading