[p5.js 2.0+ Bug Report]: Large slowdown in `p5.Graphics.set()` compared to v1.11.x

[SableRaf]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• WebGPU
• p5.strands
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.3.0

Web browser and version

• Chrome Version 151.0.7922.34 (Official Build) (arm64)
• Safari Version 26.5.2 (21624.2.5.11.8)
• Firefox 152.0.4 (aarch64)

Operating system

macOS 26.5.2 (25F84) Tahoe

Steps to reproduce this

Description

Calling set() on a p5.Graphics buffer is considerably slower in p5.js 2.3.0 than in 1.11.12. Note: directly modifying pixels[] performs about the same in both versions.

I first noticed the issue when trying to run the following sketch in p5.js 2.3.0: https://openprocessing.org/@megamitts/2979162

Benchmark

I made a quickly vibe coded benchmark sketch to systematically test the issue. It updates a 100 × 100 p5.Graphics buffer over multiple frames and prints the averaged results to the console.

In this test in Chrome, set() was about 6.9 times slower in 2.3.0 than in 1.11.12.

p5.js version	set()	pixels[]	set() slowdown vs pixels[]
1.11.12	1.85 ms	1.10 ms	1.7×
2.3.0	12.79 ms	1.16 ms	11×

I got comparable results, with slowdowns between ~9× and ~17×, in Safari and Firefox.

Reproduction

Run the benchmark sketch in p5.js 1.11.x, then in 2.x

[BHARATH0153]

@SableRaf please assign

[ksen0]

@BHARATH0153 please do not request assignment in large volumes, this will result in a ban. You have a PR out, please do not request assignment until it is merged. Large volume or requests slow down triage and review for everyone, so thanks for understanding.

In this particular case, the issue is also quite complex, and would require that the comment requesting assignment demonstrates understanding of the problem and provides a possible solution, so just requesting like this would not be sufficient.

[perminder-17]

So, whoever contributor is interested in solving this issue, I've some thoughts on this which can probably help whoever interested.

So, in my opinion there's two things involved in it.

When I added some perfs, I was able to detect the slowest block of the code which is this one:

p5.js/src/core/p5.Renderer2D.js

Line 616 in a0e76cf

[r, g, b, a] = imgOrCol._getRGBA([255, 255, 255, 255]);

which leads me to the function of _getRGBA which is here:

p5.js/src/color/p5.Color.js

Line 720 in a0e76cf

_getRGBA(maxes=[1, 1, 1, 1]) {

So, to get some more fps you can probably optimize this function. _getRGBA() is slow because it does a color-space conversion, so to optimize it we can cache its result. For eg: The first time the value is computed (the slow part), we store it on the color object, and every later call just returns that stored value instead of recomputing. Also, whenever the color changes in setRed, setGreen, setBlue, setAlpha, or the _color setter -- we clear the cached value. Then the next time the value is requested, it is recomputed fresh and saved again.

Second thing which is the main thing and it can let us know why it's slow from v1. p5's Friendly Error System (FES) validates function arguments using Zod. Every p5.prototype method (like noise() and set()) is wrapped once by a decorator, and on each user-level call its arguments are checked against a Zod schema. So if your loop calls set() and noise() 10,000 times each, that's about 20,000 Zod validations per frame, which is heavy.

So, to increase the fps we can probably use the minified version or use p5.disableFriendlyErrors = true;