Hacker News Reader

Comment by seabass | Hacker News Reader

I was surprised by the source including a bunch of try/catch, which results in deopts for that code path as far as I understand, given that the stated benefit over Zod and other validators was that this should be run in performance critical code. I’d be curious to see benchmarks that show whether this is faster than zod, valibot, and zod4 mini in hot code paths.

View on HN

We do use try/catch in a few places. However, in normal operations (valid input), no exceptions are thrown - the try/catch blocks are present in certain validators but do not execute their catch clauses. AFAIK, modern engines generally don’t impose large steady-state penalties merely for the presence of a try/catch when no exception is thrown; the measurable cost is usually when exceptions are actually thrown. When an element/property fails, the catch is used to construct precise error paths. That’s intentionally trading some failure-path overhead for better developer diagnostics.

In the new few days, I'll prepare benchmarks to compare with Zod and Valibot!

The information I have on this could be outdated, so take this with a grain of salt, but it used to be the case that in hot code paths the presence of a try/catch would force a deoptimization whether or not you throw. The optimizing compiler in v8, for example, would specifically not run on any functions containing try/catch due to its inability to speculatively inline the optimized code. If you're feeling up to it, you can prove whether that is still the case with `d8 --allow-natives-syntax --trace-deopt ./your-script.js` and sprinkle in some `%OptimizeFunctionOnNextCall` in your code. I did a quick search for `try {` in the zod 4 source and didn't see anything, so I suspect that the performance issues surrounding try/catch are still at least somewhat around, unless they are simply avoiding try/catch for code cleanliness which could totally be the case. Regardless, I'd encourage you to look into whether plain old boolean return values in your validators would work for your project. Just include the `throw` part without all the `try/catch` and the code itself will likely be simpler, faster, and easy for the JIT to optimize. Good luck on those benchmarks.

Hey, this comment was actually very helpful. While running benchmarks, I noticed my union validator was consistently underperforming, and your insight about try/catch deoptimization made it much easier to pinpoint the issue. I ended up updating the validation logic to not use try catch frivolously and I saw significant performance improvement.

For benchmarks, I forked Zod, which already included benchmarks comparing Zod 4 against Zod 3. Here are the results (in README.md) if you're interested:

https://github.com/nimeshnayaju/zod

I noticed significantly better performance than both Zod 3 and Zod 4 across most validation scenarios (especially validations that involved rules like min/max length, etc), with the exception of simple object parsing.

I also forked another benchmark suggested in a different comment if you're interested (I noticed similar results).

https://github.com/nimeshnayaju/valibot-benchmarks

OP, you could potentially leverage an existing benchmark suite: https://naruaway.github.io/valibot-benchmarks/

Thank you, this is quite helpful. Will take a detailed look very soon!

How do you know you're tool is more performant?

Hey, I did some benchmarks if you're interested - benchmarks results are in the README.md.

https://github.com/nimeshnayaju/zod (Fork of Zod's repo which already included benchmarks comparing Zod 4 against Zod 3, so I simply integrated my validation library)

https://github.com/nimeshnayaju/valibot-benchmarks (An unofficial benchmark suggested in another comment comparing Valibot against Zod)

Hey, thanks for the link! I was able to add the library to the benchmark quite easily. Here's the fork if you're interested:

https://github.com/nimeshnayaju/valibot-benchmarks

I have included the results I obtained from running the benchmark in the README.md. I'd love for you to also take a look at the changed code to see if I may have missed something with the integration. Curious to hear your feedback too!

Nicely done, and thanks for following up!

Reply on news.ycombinator.com