Skip to content

Fast path for --no-deprecation #90

Closed as not planned
Closed as not planned
@H4ad

Description

@H4ad

About the fast path

In the code of process.emitWarning, deprecations are ignored when --no-deprecation flag is passed (reference).

Instead of creating the warning object and then discarding when the flag is true, we could just check earlier and just skip the rest of the method when type is DeprecationWarning.

There are some places that could benefit from this tiny change.

Going further with improvements

What if we add guards to those places to avoid any computation at all when --no-deprecation is true?

I did some experiments with esm internal resolve and by putting an if guard for process.noDeprecation on line 106, and the results is not that bad:

                                                                              confidence improvement accuracy (*)   (**)   (***)
esm/cjs-parse.js n=100                                                                       -0.69 %       ±2.91% ±3.91%  ±5.16%
esm/esm-loader-defaultResolve.js specifier='./relative-existing.js' n=1000                    0.76 %       ±4.52% ±6.12%  ±8.20%
esm/esm-loader-defaultResolve.js specifier='./relative-nonexistent.js' n=1000                 0.26 %       ±4.80% ±6.47%  ±8.62%
esm/esm-loader-defaultResolve.js specifier='node:os' n=1000                            *      7.18 %       ±6.08% ±8.14% ±10.71%
esm/esm-loader-defaultResolve.js specifier='node:prefixed-nonexistent' n=1000                -2.21 %       ±6.18% ±8.30% ±10.96%
esm/esm-loader-defaultResolve.js specifier='unprefixed-existing' n=1000                *      9.70 %       ±7.34% ±9.84% ±12.96%
esm/esm-loader-defaultResolve.js specifier='unprefixed-nonexistent' n=1000                    1.14 %       ±2.07% ±2.77%  ±3.64%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 7 comparisons, you can thus
expect the following amount of false-positive results:
  0.35 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.07 false positives, when considering a   1% risk acceptance (**, ***),
  0.01 false positives, when considering a 0.1% risk acceptance (***)

node benchmark/run.js esm

I think the results could be even better, this benchmark is a little bit flaky as you can see by the accuracy.

What about --no-warnings?

Well, at first I thought we could do the same for --no-warnings, add an if statement and avoid calling process.emitWarning, but NodeJS just unsubscribe the listener when --no-warnings is set , but they won't stop the event from being emitted, also, there are MANY places where process.on('warning is used, so I don't think we could do anything here.

Conclusion

So, in the end, we have two questions:

  • Does it worth moving the noDeprecation before the object creation?
  • Does it worth adding fast path for every location that emits deprecations?

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions