Avoid using destroy hook on async-hooks

There is a new development on V8/Nodejs sides (Node16 and will be backported to Node14) that should optimize async-hooks, but from another side, if destroy hook is set, it will cause performance degradation

I’m not sure it is possible to avoid the use of destroy here but better keep it in mind

https://github.com/nodejs/node/pull/36394 https://github.com/nodejs/node/pull/38577

Before:

❯ ./node-base benchmark/async_hooks/promises.js
async_hooks/promises.js asyncHooks="enabled" n=1000000: 255,804.136249129
async_hooks/promises.js asyncHooks="enabledWithDestroy" n=1000000: 161,508.90344245007
async_hooks/promises.js asyncHooks="enabledWithInitOnly" n=1000000: 304,650.28581800853
async_hooks/promises.js asyncHooks="disabled" n=1000000: 1,558,729.7299161875

After:

❯ ./node benchmark/async_hooks/promises.js
async_hooks/promises.js asyncHooks="enabled" n=1000000: 1,059,976.9918850197
async_hooks/promises.js asyncHooks="enabledWithDestroy" n=1000000: 155,428.08296446863
async_hooks/promises.js asyncHooks="enabledWithInitOnly" n=1000000: 972,299.3745827201
async_hooks/promises.js asyncHooks="disabled" n=1000000: 1,548,472.043353055

[mcollina]

Another thing I’d like to look at is leveraging the executionAsyncResrouce approach at some point to see if we can use fewer hooks.

executionAsyncResource has been designed for this exact need. The destroy hook is a known performance issue and it should not be used as it creates an extremely heavy toll on the GC and Node.js in general (it’s a call from C++ to JS when every promise or native resource is collected).

FWIW, you can also take a look at https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage. It’s going to stabilize before the rest of the async_hooks machinery.

All the above was part of a long-term plan to improve the performance of Node.js when APMs are used. Take a read at https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit to get the gist of the plan. Some things are a bit outdated, but it’s still going.

[michaelgoin]

Thanks! That is definitely why I want to look into it. I have previously done a quick experiment where some supported promise cases broke, so I think we are gonna have to dig through where our existing (and old) design and assumptions need to be reworked and if there are any limitations for what we are trying to support that just aren’t possible by using the new mechanisms. I definitely expect we’d benefit greatly, though.

I appreciate sharing the plan doc, we’ll definitely take a look.