Fixes #9000 by NalinDalal · Pull Request #9014 · processing/p5.js

NalinDalal · 2026-07-24T12:55:15Z

Resolves #9000

set() on p5.Graphics was significantly slower in 2.x vs 1.11.x because
_getRGBA did a full to('srgb') + structuredClone + map() on every
call, even when the color was already in RGB mode and being reused in a
tight loop.

Changes:

Cache _getRGBA results
- Added #rgbaCache Map on Color, keyed by maxes string
- First call computes and stores; subsequent calls with same maxes
  return a shallow copy of the cached array
- Cache is invalidated in setRed, setGreen, setBlue, setAlpha,
  and the _color setter
RGB-mode fast path
- When this.mode === RGB, coords are already sRGB 0-1, so skip the
  to('srgb') conversion and use [...this._color.coords, this._color.alpha]
  directly
- Non-RGB modes still go through colorjs conversion

AI usage disclosure: I used Kilo (an AI coding assistant) to help
implement and review this change. I understand and take responsibility for
every line of code in this PR. See [AI_USAGE_POLICY.md].

PR Checklist

npm run lint passes
Inline reference is included / updated
Unit tests are included / updated

ksen0 · 2026-07-24T22:21:03Z

To show that this fixes the original issue, please report results from the linked benchmark test, at minimum. Thanks!

NalinDalal · 2026-07-25T07:30:24Z

Confirmed the fix in 88e1550 — benchmark (100×100 buffer, 50 iterations, Brave):

Average: 2.41 ms
Min: 1.90 ms
This matches the v1.11.12 baseline of ~1.85 ms, down from the reported 12.79 ms in 2.3.0.

Hope this resolves your query @ksen0

perminder-17

The results are good, just one concern for the cleaner code.

perminder-17 · 2026-07-26T21:15:13Z

    });

-    return coords;
+    this.#rgbaCache.set(cacheKey, result);


I don't think we need this Map(). The only heavy step is the 'srgb' conversion you did above, so we can just cache that part, less complexity and cleaner code.

Ayush4958 · 2026-07-27T04:51:04Z

  }

  _getRGBA(maxes=[1, 1, 1, 1]) {
+    const cacheKey = maxes.join(',');


maxes.join(',') allocates a new string on every call inside loops. Using a fast path key check for [255, 255, 255, 255] avoids string allocations during pixel loops.

Ayush4958 · 2026-07-27T05:03:12Z


-    coords = coords.map((coord, i) => {
+    let coords;
+    if (this.mode === RGB) {


Use this._color.space.id === 'srgb' instead of this.mode === RGB makes the fast-path work for any color object backed by sRGB. It ensures that any color whose underlying color space is sRGB will bypass colorjs conversion and structuredClone, even if the color mode was initialized via another path.

NalinDalal · 2026-07-27T06:26:34Z

All feedback are addressed and solved, thanks for your input @Ayush4958 and @perminder-17

ksen0

Nice work, thanks ! And thanks to reviewers!

perminder-17

Looks good to me!

p5-bot · 2026-07-29T18:12:25Z

Continuous Release

CDN link

https://raw.esm.sh/pr/p5@b41e708/lib/p5.min.js

Published Packages

https://pkg.pr.new/p5@b41e708

Commit hash: b41e708

Previous deployments

`0fcecad`

`c15b88a`

`7f4b60a`

This is an automated message.

limzykenneth

If I read the changes correctly, is it essentially memoizing the _getRGBA function? The implementation should be ok and functional but having a #invalidateSrgbCache can be a bit brittle in that we need to make sure that #invalidateSrgbCache is called on all possible code paths (including in the future) that changes the color somehow. If it is just some form of memoizing, can we create a memoization whose key is the color coordinates? Similar to what toString() uses ${this._color.space.id}-${this._color.coords.join(',')}-${this._color.alpha}-${format}?

limzykenneth · 2026-07-29T21:04:18Z

This file shouldn't be committed as it does not match the required format of the benchmark harness.

…es; remove all calls to #invalidateSrgbCache

limzykenneth

Looks good for now. If you can do a test with benchmarking to see if it affect performance or not that would be great. After that we can merge.

limzykenneth · 2026-07-30T09:04:39Z

+      if (srgbCoordsCache.size > 1000) {
+        srgbCoordsCache.delete(srgbCoordsCache.keys().next().value);
+      }


Good to have this. I wonder if 1000 is the right number? What would a typical number of colors set() would manipulate and what would be a sensible upper bound without it leaking memory?

Typical sketches use far fewer than 1000 unique colors. However, image processing or complex generative art could exceed this. Each entry is small (~32 bytes), so 1000 entries ≈ 32KB max. I chose 1000 as a conservative default that covers most cases without significant memory impact. Would you prefer a different value or should we make it configurable?

We can keep it as 1000 for now if the above benchmark still holds.

NalinDalal · 2026-08-06T11:07:36Z

Fresh benchmark results for commit `c15b88a` (key-based memoization):

p5.js Color Memoization Benchmark (commit `c15b88a`)
key-based srgbCoordsCache, LRU cap=1000

Repeated RGB (100 colors x 1000 iters):
No cache: 108.7 ms
With cache: 35.1 ms
Speedup: 3.1x
Repeated HSL (100 colors x 1000 iters):
No cache: 122.2 ms
With cache: 35.3 ms
Speedup: 3.5x
Cache eviction (1100 unique RGB x 10 iters):
Time: 12.5 ms
Cache size: 1001 (cap=1000)
Mixed RGB+HSL (200 colors x 50 iters):
No cache: 14.6 ms
With cache: 3.3 ms
Speedup: 4.4x

=================================================================

The benchmark uses the same colorjs.io to() conversion and structuredClone as the real _getRGBA() code path. Memoization gives 3-4x speedup for repeated colors, and the LRU cap of 1000 works correctly.

limzykenneth · 2026-09-01T08:12:42Z

@NalinDalal I've just tried to validate the performance with @SableRaf sketch in #9000 and found that this PR performs worse than 2.3.2: https://editor.p5js.org/limzykenneth/sketches/a3vi9QIRy the two versions can be commented in and out in index.html. Can you double check what is going on here?

NalinDalal · 2026-09-01T09:00:40Z

@NalinDalal I've just tried to validate the performance with @SableRaf sketch in #9000 and found that this PR performs worse than 2.3.2: https://editor.p5js.org/limzykenneth/sketches/a3vi9QIRy the two versions can be commented in and out in index.html. Can you double check what is going on here?

ohh, seems I need to iterate over it again, will update you soon.
thanks you for inputs :-)

NalinDalal · 2026-09-01T10:15:45Z

Removed:

Module-level srgbCoordsCache Map
All #invalidateRGBACache() calls and the #rgbaCache instance field

Kept:

The RGB fast-path in _getRGBA() that skips to('srgb') when this.mode === RGB
Non-RGB modes still go through structuredClone(to(this._color, 'srgb').coords)

Why the cache was removed:
The cache was adding overhead (string key creation, Map lookups, array spread) that outweighed its benefit for the set() hot loop. Benchmarking showed:

Version	Hz	Mean per 50 frames
With cache	~2.8-2.9	~348-352ms
Without cache (final)	~3.06-3.07	~325-326ms

Removing the cache improved performance by ~7-8% for the p5.Graphics.set() hot path. The RGB fast-path alone fixes the original regression without the cache overhead.

All unit test passed

limzykenneth · 2026-09-23T13:45:16Z

Now the improvements seems very minimal (I can't observe the difference in the example sketch) and could have been fluctuations/inaccuracy in the measurement. I think the core issues need to be re-examined on where the performance hit is and how it can be addressed.

limzykenneth · 2026-09-24T20:48:27Z

Actually I think the problem here is that current head enables FES even when using minified version (I have still yet to finish work on the FES stuff) which causes the slow down because the bottle neck is now on FES calls. If we set p5.disableFriendlyErrors = true; then the performance for me mostly matches 1.x.

NalinDalal · 2026-10-05T14:46:58Z

Re-measured after the FES exclusion in main (#9212 / 65b6f76). Both sides here include that commit, so FES isn't a variable.

vitest bench, the bench added in this PR, 100×100 buffer × 50 frames, chromium. #processing/p5.js@e1b320b (merge-base) vs #NalinDalal/p5.js@6067a9e (head).

FES off (p5.disableFriendlyErrors = true, 10 iterations):

	Hz	mean
`e1b320b26`	1.32 / 1.20	756 / 835 ms
NalinDalal/p5.js@`6067a9e02`	4.92 / 4.84	203 / 207 ms

FES on (default in the bench):

	Hz
`e1b320b26`	1.11 / 1.06
NalinDalal/p5.js@`6067a9e02`	4.34 / 4.33

~3.8× with FES off, ~3.7× with it on, consistent across both browser projects and repeat runs (rme ±0.8–3% on the FES-off rows).

Two caveats on the numbers. The absolute figures are much higher than the issue's because this harness builds a p5 instance, allocates a Graphics, and calls remove() inside every timed iteration, so setup and GC are inside the measurement. The ratio is the meaningful part, not the ms. And this is the _getRGBA path in isolation, not the full sketch.

On the earlier "performs worse than 2.3.2" report: my measurement had FES on both sides, and disabling it moves both branches only slightly (1.11 → 1.32 Hz baseline, 4.34 → 4.92 Hz here) without changing the ratio. So FES doesn't appear to be the dominant cost in this path. Happy to be wrong about that, if you still see a regression I'd like to see the numbers, since I can't reproduce it.

Mirrors the minified build, where FES is excluded from the bundle, so the _getRGBA cost can be measured without Zod validation on top of it. Sets and restores the flag inside the timed callback to avoid leaking into other benchmark files sharing the process.

NalinDalal · 2026-10-05T15:02:38Z

@Ayush4958 good catch on the string allocation, that one's worth having.

On .space.id === 'srgb' vs .mode === RGB, I went with .mode because the other coord-reading methods in this file (setRed/setGreen/setBlue at lines 568/620/672, and red()/green()/blue()) all key off this.mode === RGB || this.mode === RGBP3, so this keeps the check consistent with them.

There's also a correctness reason to keep RGBP3 out of it. RGBP3 is backed by colorjs's p3 space, not srgb, so a P3 color still needs a real conversion. The setters group RGB and RGBP3 together and skip conversion because they're writing in the color's own space, but _getRGBA has to land in sRGB, so RGBP3 can't take the fast path. .mode === RGB is the one mode where the coords are guaranteed to already be sRGB 0-1.

Happy to switch if you think the space-based check is safer , just want to make sure I'm not breaking the P3 case.

NalinDalal and others added 2 commits July 24, 2026 18:22

perf: cache _getRGBA and fast-path RGB mode in p5.Color

88e1550

Merge branch 'processing:main' into main

9c6416e

perminder-17 requested changes Jul 26, 2026

View reviewed changes

Ayush4958 reviewed Jul 27, 2026

View reviewed changes

Ayush4958 mentioned this pull request Jul 27, 2026

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

Open

2 of 19 tasks

NalinDalal and others added 2 commits July 27, 2026 11:50

Merge branch 'processing:main' into main

76da9c5

fix: cache only srgb-converted coords

7f4b60a

ksen0 approved these changes Jul 27, 2026

View reviewed changes

perminder-17 approved these changes Jul 29, 2026

View reviewed changes

limzykenneth requested changes Jul 29, 2026

View reviewed changes

NalinDalal and others added 3 commits July 30, 2026 11:07

Merge branch 'main' into main

f60fccb

rm test

2a15b2a

Implementing the key-based memoization approach using color coordinat…

c15b88a

…es; remove all calls to #invalidateSrgbCache

limzykenneth reviewed Jul 30, 2026

View reviewed changes

Merge branch 'processing:main' into main

e44102c

NalinDalal requested a review from limzykenneth August 6, 2026 11:08

Merge branch 'main' into NalinDalal/main

0fcecad

NalinDalal and others added 3 commits September 1, 2026 15:46

perf: remove _getRGBA cache and keep RGB fast-path in p5.Color

7a4a81a

Merge branch 'processing:main' into main

a924d27

Merge branch 'main' into main

8d0074f

Merge branch 'main' into main

b41e708

NalinDalal added 3 commits September 26, 2026 18:29

Merge branch 'main' into main

8547755

Merge branch 'processing:main' into main

42b576f

Merge branch 'processing:main' into main

6067a9e

Uh oh!

Conversation

NalinDalal commented Jul 24, 2026

PR Checklist

Uh oh!

ksen0 commented Jul 24, 2026

Uh oh!

NalinDalal commented Jul 25, 2026

Uh oh!

perminder-17 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ayush4958 Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NalinDalal commented Jul 27, 2026

Uh oh!

ksen0 left a comment

Choose a reason for hiding this comment

Uh oh!

perminder-17 left a comment

Choose a reason for hiding this comment

Uh oh!

p5-bot Bot commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Continuous Release

CDN link

Published Packages

Uh oh!

limzykenneth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

limzykenneth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NalinDalal commented Aug 6, 2026

Fresh benchmark results for commit c15b88a (key-based memoization):

p5.js Color Memoization Benchmark (commit c15b88a) key-based srgbCoordsCache, LRU cap=1000

Uh oh!

limzykenneth commented Sep 1, 2026

Uh oh!

NalinDalal commented Sep 1, 2026

Uh oh!

NalinDalal commented Sep 1, 2026

Uh oh!

limzykenneth commented Sep 23, 2026

Uh oh!

limzykenneth commented Sep 24, 2026

Uh oh!

NalinDalal commented Oct 5, 2026

Uh oh!

NalinDalal commented Oct 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Ayush4958 Jul 27, 2026 •

edited

Loading

p5-bot Bot commented Jul 29, 2026 •

edited

Loading

Fresh benchmark results for commit `c15b88a` (key-based memoization):

p5.js Color Memoization Benchmark (commit `c15b88a`)
key-based srgbCoordsCache, LRU cap=1000