Discussion: The performance vs safety trade off of FES (Zod) validation on Math classes (p5.Vector, p5.Matrix)

Overview

I open this discussion regarding the performance impact of the Friendly Error System (FES) on high frequency Math classes (like p5.Vector & p5.Matrix) see where the maintainers stand on the trade-off between beginner safety and default performance.

Bottleneck

Currently, FES wraps instance methods on p5.prototype, which includes p5.Vector methods. It relies on Zod (zod/mini in src/friendly_errors/param_validator.js) for parameter schema validation.

While Zod overhead is completely negligible for standard drawing APIs like ellipse(), vectors are uniquely positioned.

In creative coding, beginners frequently update vectors inside tight, performance sensitive loops.

When methods like Vector.add() are called 10,000+ times per frame, Zod validation executes synchronously 10,000+ times, heavily suffocating the actual math operations and causing massive framerate drops.

The Trade off (Safety vs. Speed)

We know that power-users can bypass this by manually setting p5.disableFriendlyErrors = true or using the minified build. However, beginners usually don't know this flag exists. As a result, they hit a very low performance ceiling early on when building particle systems.

If we were to disable FES parameter validation by default specifically for p5.Vector and p5.Matrix, we would drastically raise the out of the box performance ceiling.

However, this comes with a major trade-off :-
If a beginner writes vector.add("hello"), they would no longer get a helpful FES message. The function would simply fail with raw JavaScript behavior (e.g., returning NaN).

Discussion Points

Before proposing any pull requests, I wanted to get the community's and maintainers' thoughts on this:

1. Option A (Status Quo): Is beginner safety on Math classes worth the severe default performance penalty in loops? Should we simply rely better on teaching beginners about the disableFriendlyErrors flag?
2. Option B (Selective Bypass): Should we consider an internal blocklist that skips FES wrapping for p5.Vector and p5.Matrix, treating them as "high-performance" classes where raw JS errors are accepted in exchange for speed?
3. Any middle ground available ?

Start with src/friendly_errors/param_validator.js and inspect how FES wraps p5.Vector and p5.Matrix methods. Measure validation overhead in high-frequency vector and matrix calls, then review the discussion options with maintainers. Done means reaching an agreed direction before proposing a concrete change.