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:
- 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?
- 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?
- Any middle ground available ?
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 includesp5.Vectormethods. It relies on Zod (zod/miniinsrc/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 = trueor 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.Vectorandp5.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., returningNaN).Discussion Points
Before proposing any pull requests, I wanted to get the community's and maintainers' thoughts on this:
disableFriendlyErrorsflag?p5.Vectorandp5.Matrix, treating them as "high-performance" classes where raw JS errors are accepted in exchange for speed?