add more benchmarks

[gvergnaud]

Hey! Thanks for creating this repository, I've been meaning to create a benchmark like this one for a long time but never took the time to do so.

I think that your initial benchmark is a bit skewed because simple functions taking always the same input get JIT compiled away into very few instructions and don't reflect real world use cases so I took the liberty of creating two more examples using random inputs:

> ts-node --esm tests/always-last-digit.mts

  .exhaustive():
    4 094 630 ops/s, ±0.07%       | 99.6% slower

  .otherwise():
    4 057 100 ops/s, ±0.54%       | 99.61% slower

  .run():
    4 050 550 ops/s, ±0.09%       | slowest, 99.61% slower

  if/else:
    1 035 603 940 ops/s, ±0.07%   | fastest

  switch:
    1 034 047 968 ops/s, ±0.16%   | 0.15% slower

  ternary:
    1 035 113 339 ops/s, ±0.12%   | 0.05% slower

Finished 6 cases!
  Fastest: if/else
  Slowest: .run()

ts-pattern is 250x slower on this benchmark. (always the same input)

> ts-node --esm tests/random-digit.mts

  .exhaustive():
    4 966 468 ops/s, ±0.14%    | 90.15% slower

  .otherwise():
    4 923 483 ops/s, ±0.56%    | slowest, 90.24% slower

  .run():
    4 935 394 ops/s, ±0.09%    | 90.21% slower

  if/else:
    50 419 903 ops/s, ±0.05%   | fastest

  switch:
    50 308 569 ops/s, ±0.34%   | 0.22% slower

  ternary:
    48 251 095 ops/s, ±0.06%   | 4.3% slower

Finished 6 cases!
  Fastest: if/else
  Slowest: .otherwise()

ts-pattern is ~10x slower with random numbers.

> ts-node --esm tests/nested-objects.mts

  .exhaustive():
    424 650 ops/s, ±2.06%      | slowest, 96.63% slower

  if/else:
    12 592 823 ops/s, ±0.13%   | fastest

Finished 2 cases!
  Fastest: if/else
  Slowest: .exhaustive()

ts-pattern is ~30x slower with random data structures.

The fact that ts-pattern is always slower is to be expected, given that it provides a nicer DX by supporting any kind of pattern nested in any possible way, property selection, etc. At the end of the day, data validation and conditional statements aren't likely to be the performance bottleneck of an app, so IMHO that's a tradeoff worth taking in many cases

[bdbaraban]

Love it! Thank you for the in-depth follow-up, these examples are certainly more reflective of real-world use cases. I hope this information can be helpful for developers considering the library. Feel free to merge this in if you wish.

The fact that ts-pattern is always slower is to be expected, given that it provides a nicer DX by supporting any kind of pattern nested in any possible way, property selection, etc. At the end of the day, data validation and conditional statements isn't likely to be the performance bottleneck of an app, so IMHO that's a tradeoff worth taking in many cases

FWIW I'm with you, when it comes down to it we're talking about 10-30x thousandths of milliseconds here. I'm a big fan of ts-pattern and greatly appreciate your continued work improving it! 🫡