perf: improve instantation speed by dynamic formatter generation

[Uzlopak]

As I see that @trim21 is active in this repo, I wanted to suggest a change, which has maybe more impact than #100

This is just a poc. It is not complete regarding the serialization.

To have some useful performance benchmark, i disabled stacktrace generation.

before:

uzlopak@Battlestation:~/workspace/fastify-org/fastify-error$ node benchmarks/instantiate.js
instantiate Error x 5,245,780 ops/sec ±0.37% (192 runs sampled)
instantiate FastifyError x 238,523,493 ops/sec ±0.07% (196 runs sampled)
instantiate FastifySpecialError x 20,584,535 ops/sec ±0.54% (194 runs sampled)

after:

uzlopak@Battlestation:~/workspace/fastify-org/fastify-error$ node benchmarks/instantiate.js
instantiate Error x 5,208,812 ops/sec ±0.22% (192 runs sampled)
instantiate FastifyError x 238,148,483 ops/sec ±0.08% (195 runs sampled)
instantiate FastifySpecialError x 144,541,760 ops/sec ±0.12% (194 runs sampled)

Obviously it gets slower if type casting is feature complete. But I assume, that it is still faster than calling util.format every time.
Maybe it is useless, as stacktrace is always the biggest perf bottleneck. But in the case, somebody disables stacktrace on production services (which is i think anyway best practice) it shoiuld have an impact on perf.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[trim21]

maybe just use string variable in FastifyError

[trim21]

instantiate Error x 1,895,804 ops/sec ±1.62% (184 runs sampled)
instantiate FastifyError x 173,772,171 ops/sec ±2.15% (179 runs sampled)
instantiate FastifySpecialError x 102,105,886 ops/sec ±2.52% (179 runs sampled)

[Uzlopak]

More likely to build FastifyError dynamically.

[trim21]

I didn't get it

[Uzlopak]

nevermind.

Anyhow. this is just a poc. If there is interest, I could improve it.

[Uzlopak]

@ivan-tymoshenko
This is maybe very similar to fast-json-stringify

[ivan-tymoshenko]

@Uzlopak sorry, I don't understand. Can you explain, please?

[Uzlopak]

new benchmarks:
before:
node benchmarks/instantiate.js
instantiate Error x 5,148,366 ops/sec ±0.28% (191 runs sampled)
instantiate FastifyError x 121,849,157 ops/sec ±0.50% (190 runs sampled)
instantiate FastifyError arg 1 x 14,033,361 ops/sec ±0.25% (194 runs sampled)
instantiate FastifyError arg 2 x 10,830,852 ops/sec ±0.33% (191 runs sampled)

after:
node benchmarks/instantiate.js
instantiate Error x 5,049,694 ops/sec ±0.26% (193 runs sampled)
instantiate FastifyError x 236,957,612 ops/sec ±0.09% (193 runs sampled)
instantiate FastifyError arg 1 x 83,758,765 ops/sec ±0.91% (185 runs sampled)
instantiate FastifyError arg 2 x 63,728,097 ops/sec ±2.10% (179 runs sampled)

Like I wrote above, i disabled stack tracing to get a more comparable result. Generating the Stack is horrible slow.

[Uzlopak]

@ivan-tymoshenko

I use now the message string as pattern to create the format function once instead of calling format(message, args) every time.

[Uzlopak]

With default stackTraceLimit

before:
node benchmarks/instantiate.js
instantiate Error x 322,998 ops/sec ±2.65% (137 runs sampled)
instantiate FastifyError x 231,124 ops/sec ±1.33% (188 runs sampled)
instantiate FastifyError arg 1 x 171,481 ops/sec ±1.44% (182 runs sampled)

after:
node benchmarks/instantiate.js
instantiate Error x 304,488 ops/sec ±3.00% (138 runs sampled)
instantiate FastifyError x 224,038 ops/sec ±1.68% (187 runs sampled)
instantiate FastifyError arg 1 x 188,652 ops/sec ±1.69% (188 runs sampled)
instantiate FastifyError arg 2 x 180,878 ops/sec ±1.80% (176 runs sampled)

In conclusio:

It is signigificant faster if we set stackTraceLimit to 0. If we use default stackTraceLimit, we are not definetly not faster.

[trim21]

there is already benchmarks/no-stack.js for this?

[mcollina]

I don't think benchmarking without stacktraces is worthwhile. Stacktraces are incredibly useful to determine where a problem originated.

What is the goal of the change? What are are you trying to achieve?

[jsumners]

I think we already had a discussion and determined that we do not want to omit stack traces. They are the purpose of the error.

[trim21]

What is the goal of the change? What are are you trying to achieve?

improve string formatting perf. disabling stack trace is would make it easier to focus on the perf of string formatting.

[Uzlopak]

I think, that in production Environment disabling stacktraces is a viable decision. In development using stacktraces make obviously sense.

[jsumners]

Sure, it's a viable decision. But I would recommend against it. Without the stack trace you are left with very little information to determine the cause of issues.