Compile-time performance optimization

[XiNiHa]

Is your feature request related to a problem? Please describe.
I've been enjoying this library a lot! However, after looking at the source, I'm a bit worried about the overall performance, since it looks much more expensive than usual conditional checks.

Describe the solution you'd like
Introduce some kind of compilation step (Babel/SWC plugins? or even standalone) to optimize out the API calls.

Describe alternatives you've considered
Not sure. Maybe waiting until JS engines natively support pattern matching and JIT for it? :P

[gvergnaud]

Hey, thanks for the suggestion.

pattern matching with ts-pattern will always be more expensive than native support, that's true, but I prefer to keep it as a runtime-only library. The main reason is that it's way easier to install in use in any environment than a compiler.

That said, I'm profiling ts-pattern regularly to make it as fast as possible, and I'll keep doing so :)

[BaeoMaltinsky]

I know this issue is closed, but I'm asking out of curiosity: do you have benchmarks that quantify the difference between ts-pattern and hand-written control flow with respect to performance?

[bdbaraban]

I was also curious to compare performance of ts-pattern to built-in conditionals, and have spun up some simple benchmarks. I wrote a discussion post here, but tl;dr; I'm finding that match statements execute ~100% more slowly than built-in control flows.

https://github.com/bdbaraban/ts-pattern-benchmark

[LukeDefeo]

@bdbaraban looking at your benchmark it seems to be over 1000 times slower than if/else
1 313 796 ops/s vs
1 039 743 389 ops/s

Seems like a pretty huge hit and I don't think many apps can justify this

@gvergnaud How much overhead do your internal benchmarks show?

[darrylnoakes]

It comes down to "what are you matching, and how often?" Yes, it may well be 1000 times slower, but over 1 Mops/s is still under 1 us/op, and I understand that each of those ops is a ten-branch match.

Unless you have a tremendous amount of branches (that also have a rather even distribution of matching probability) and/or run a lot of matching calls, this shouldn't really be an issue. Obviously, you shouldn't implement something performance critical with it, like a UI framework (e.g., Vue), but I think most apps won't have an issue with this. You could run a hundred of those ten-branch matches every frame and still only use about 0.1 ms of the 16 ms time budget.

I use it for matching API status codes and doing basic API data validation. Performance at such a level doesn't really matter for this, and ts-pattern makes the code much neater and maintainable.

It all depends what you're doing :).

P.S. I don't think the numbers in the Readme have been updated since the better benchmarks were added. With random numbers, it's ~5 Mops/s vs ~50 Mops/s; with "random data structures", it's ~0.4 Mops/s vs ~12.5 Mops/s.