"Incremental search" behavior of "SEARCH" view field can cause crash

[dagnall53]

Describe the problem

When using the "global" search in a large project, the IDE can crawl to a halt as the search term is typed in. In some situations I have had the IDE turn unresponsive with just a single letter typed in - preventing me from adding more elements to the search term.

I believe that this is due to it trying hard to find all instances of the search term AS it is being typed in.

To reproduce

1. Open a large sketch.
2. Open the "SEARCH" view.
3. Type a letter in the "Search" field.

Expected behavior

Triggering the search only after the user clicks a button or presses Enter would prevent the problem.

Arduino IDE version

2.0.1

Operating system

Windows

Operating system version

10

Additional context

Additional reports

• https://forum.arduino.cc/t/search-all-sketch-dont-wait-for-enter/1093641
• https://forum.arduino.cc/t/ide-2-1-1-hangs-when-entering-search-term-in-text-box/1158462
• https://forum.arduino.cc/t/arduino-ide-2-2-1-locks-up/1176248

Keywords

• "find"
• "hot search"
• "incremental find"
• "real-time suggestions"
• "live search"
• "active search"
• "real-time"
• "realtime"
• "real time"
• "hang"
• "freeze"

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the latest nightly build
• My request contains all necessary details

[per1234]

Hi @dagnall53.

Are you able to reproduce the bug using this large project?:

https://github.com/DCC-EX/CommandStation-EX

(note that it currently takes some time to open this large sketch for the first time: https://github.com/arduino/arduino-ide/issues/1612)

I just gave it a try and did not experience any problems with the IDE going unresponsive or even using any significant amount of CPU or memory on my Windows 10 machine while searching for a single letter in the 85 files of that sketch. I do notice that the single letter search never completes (or maybe I'm just not patient enough). Once I add one additional letter and bring the number of results down to ~1000, the search finishes quickly.

---

There was a similar problem in the Arduino IDE 1.x Library Manager search: arduino/Arduino#8282
It was resolved by adding a delay before the search query was automatically applied (the user could trigger an immediate search by pressing the Enter key): arduino/Arduino#8537

[dagnall53]

@per1234 I have downloaded that sketch. - and it does take a long time for the tabs to fully appear. Interestingly, the IDE seemed to do all the indexing in about 1 minute, and I can quickly see all the library/subfile names in the pull down, but the tabs individually took about 5-10 seconds (?) each to "flash" onto the screen. It was not clear if any "work" is possible before all are available.. so I just waited the 7 minutes for the screen to stop its momentary flashing as the tabs appeared.
Big test, search all tab for "D" (initially) I got the blue bar scanning, but the code was still responsive and I could type in the 'CC' to complete the search.

I was compiling for esp32, so change dto Arduino mega in case this affects anything, I repeated the tests but (unsurprisingly) it still responded ok.

SO- NO.. Unfortunately even this big project did not allow me to demonstrate the completely unresponsive behaviour I have occasionally seen.

(Side note - given the test material!. . I started looking at an automated garden railway when I retired 10 years ago. I found the JMRI Javascript approach difficult to follow, so built a small system around RocRail. I managed to code a sound decoder for esp8266 and my own 3d printed loco, which I was rather pleased with : https://youtu.be/Pg5r6MZDhww , but it was heavily integrated into Rocrail's comms protocol which I fully admit I do not fully understand. Rob (Rocrail) has since improved his ESP8266 decoder code to an extent that my loco sound decoder approach is now irrelevant, but the sound effects on mine were interesting. )