web editor lag spike when switching between large text files when find/replace tool open

[DavieJones49]

p5.js version

1.11.13

What is your operating system?

Chromebook (school-owned)

Web browser and version

chrome

Actual Behavior

Device: Lenovo 300e Yoga Chromebook Gen 4 (school-owned).
In the web editor, when the web editor's ctrl+F text find/replace tool is open (with some text to find in it), if the user switches text files within the project editor or starts typing in the text file, the user experiences a lag spike that renders the editor chrome tab unresponsive for prolonged periods (sometimes longer than a minute). This happens when my javascript files are several thousand lines of code long or longer.

The issue makes it difficult to use the p5js web editor.

Expected Behavior

The chrome tab should not freeze for a few minutes when I switch between long text files in the editor with the text find/replace tool open.

Steps to reproduce

Steps:

1. open a project with more than one javascript files at least several thousand lines long.
2. open the editor's built-in text find/replace tool and use it to find some text in one of the files.
3. switch to the other long text file without closing the find/replace tool.
4. You can also induce the spike by editing the long code file while the find/replace tool is still open.

My project (where I experience issues): https://editor.p5js.org/davidjramirez04/sketches/sIEIjaKEI
The lag spikes are attributed to the sheer size of the code files, especially when using the text finder.
Hyperkhukku III battle simulator (google it)

[VikasKSingh05]

Thanks for the report @DavieJones49 . I tested this on Chrome, but I wasn’t able to reproduce the lag/freezing behavior when switching files with the find/replace panel open.

It may be device-specific or related to project size/memory constraints on Chromebooks. If possible, could you provide:

• Approximate file sizes / line counts
• Whether the issue happens consistently
• Any console errors
• A sample project that reproduces the issue

That would help narrow it down further.

[DavieJones49]

I use a school-managed chromebook.
This is my project I experience issues on: https://editor.p5js.org/davidjramirez04/sketches/muFbCEM_p
My project is a 3D science-fiction battle simulator, called "Hyperkhukku" (query "Hyperkhukku" on YouTube)
The issue happens to me more often than not on the chromebook. I haven't tested the issue on stronger devices.

[VikasKSingh05]

Thank you @DavieJones49 . I investigated this further locally and was able to reproduce the lag/freezing behavior while testing with the shared project and keeping the Ctrl+F persistent find panel open across large files.

The slowdown appears related to the editor search flow in client/utils/codemirror-search.js, particularly around persistent search overlays and editor updates on large documents.

During reproduction I observed:

• codemirror-search.js keyup handlers taking ~200ms+
• expensive requestAnimationFrame work in show-hint.js
• forced reflow/layout warnings during editor interactions

This seems consistent with a performance-scaling issue where persistent search overlays and editor re-rendering become very expensive on large files, especially on lower-powered devices like Chromebooks.

I’d like to continue investigating and work on a fix for this issue if that’s okay. Please assign it to me if available.

I have attached a clip of editor lag spike that I faced while reproducing the issue:

Screen.Recording.2026-05-09.154305.mp4

[DavieJones49]

For me the lag spike occurs even with autocomplete hinter OFF. (FYI)
You should also play the game :) it's fun

[skyash-dev]

looks like these lag spikes are due to large project size and not because of keyword search or autocomplete hinter.

[DavieJones49]

looks like these lag spikes are due to large project size and not because of keyword search or autocomplete hinter.

Although is is true that lag spikes sometimes happen without the use of find/replace, the find/replace tool reliably causes an extreme lag spike on this large project when switching tabs or editing code while it is open, and the text finder-associated lag spikes tend to be considerably worse / take longer to resolve than the random lag spikes.

I have reason to believe that the text finder scans the code file for every single character edit to the file, meaning that the find/replace tool runs for every keystroke when the user is typing edits. The issue can be fixed by including a 2-second delay that stops the find/replace tool from scanning the whole file until the user ceases typing edits to the file (when the text finder is opened and in use).

The bottom line is, I want the p5js text finder optimized so it doesn't break the editor for low-end devices and large files. That's why I made this bug report in the first place.