Faster optional & nullable values

[tmcw]

I think somewhere in the commit flow the deno/ tree keeps getting updated in these PRs? I'm not sure if that's intended or not.

Checking out issues, it seems like people use .optional().nullable() a lot in their Zod types. There's definitely a performance cost to that, because for that case you run ZodOptional, ZodNullable, and then the underlying type. This eliminates the creation of an intermediate ctx in the process, which boosts performance by ~10% in this case.

Before:

z.string: optional string x 8,206,017 ops/sec ±0.75% (91 runs sampled)
z.string: nullable string x 5,680,332 ops/sec ±1.01% (93 runs sampled)
z.string: nullable (null) string x 11,105,555 ops/sec ±0.75% (93 runs sampled)

After:

z.string: optional string x 9,065,250 ops/sec ±0.95% (95 runs sampled)
z.string: nullable string x 7,490,333 ops/sec ±0.49% (96 runs sampled)
z.string: nullable (null) string x 11,164,238 ops/sec ±0.69% (93 runs sampled)

[FlorianWendelborn]

@tmcw shouldn’t this same optimization also be possible for .nullish()?

[tmcw]

nullish() is a shortcut for .optional().nullable(), so this PR will increase performance somewhat for nullish as well - without changing how nullish works it isn't possible to optimize it much further.

[colinhacks]

Looks great yet again 🤙

The Deno thing is intentional - it gets built during a precommit hook into the deno subdir because I was too lazy to set up a separate repo and proper CI for it. I'll look into doing that in a push hook instead, I'm planning to overhaul the CI over the weekend.