Foreseeing runHooks becoming a hot code path, I took to making a few small micro-optimizations, improving the handled and unhandled hook performance by approximately 42% and 172% respectively on my machine (handled meaning at least one hook handler exists). Standard benchmarking caveats apply (Node V8 engine, machine-specific, benchmarks themselves limited in real-world applicability).

Before:

handled x 5,839,917 ops/sec ±0.32% (91 runs sampled)
unhandled x 7,967,106 ops/sec ±0.63% (89 runs sampled)

After:

handled x 8,306,775 ops/sec ±0.46% (92 runs sampled)
unhandled x 22,606,859 ops/sec ±0.65% (90 runs sampled)

Optimizations include:

• Removing unnecessary code (a0e6eb6)
  • Technically, this removal would allow for doAction( '__current' ) to attempt to find handlers for the internal property, though would fail after the second condition, since array would not have .handlers property. To me, it's more concerning that we're allowing for this special key to exist with special treatment in the same scope as other hook handlers.
• Avoid assignment when either unnecessary or redundant (71bd540, 9177da1)
• Performant alternatives (truthy property access on null-prototype object vs. hasOwnProperty, faa0ed3, jsperf)
  • The reason for Object.create( null ) is to avoid issues with prototype property access:
    • !! ( {} ).valueOf // true
    • !! Object.create( null ).valueOf // false

Try yourself:

npm install
npm run build
node packages/hooks/benchmark