#Improve Performance of "Find within block" and "Filter block output"

3 messages · Page 1 of 1 (latest)

oblique rampartBOT
#

Hi @valid hare. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

This appears to be a feature request / performance improvement suggestion for Warp's Find within block and Block Filtering features. Here's what the knowledge sources tell us about the current state and related issues:

Current Behavior

  • Find within block (CMD-F on macOS, CTRL-SHIFT-F on Windows/Linux) searches across all blocks from the bottom up, or can be scoped to a specific block. [Block Find]
  • Block Filtering (OPT-SHIFT-F / ALT-SHIFT-F) filters block output lines in real-time as you type. [Block Filtering]

Known Performance Issues

There are open GitHub issues that align with your concern:

  • A user reported that search is slow in long sessions and that it doesn't filter out non-matching entries, making it harder to find results. [Search is slow]
  • A critical bug report noted that the find panel re-renders several times per second, causing 200%+ CPU usage — and that closing the find panel resolved the lag. [CPU issue]

Your Suggestion

Your suggestion to add debouncing to the find/filter input is well-founded. Interestingly, Warp already uses debouncing in other parts of the editor (e.g., for syntax highlighting and error underlining in the command input) to avoid overloading function calls on every keystroke. [Syntax Highlighting Blog] Applying a similar approach to Find/Filter would be a natural extension.

Recommendation

#

Since this is an open issue, I'd recommend upvoting or commenting on the existing GitHub issue to signal demand:
👉 github.com/warpdotdev/Warp/issues/6610

The knowledge sources do not confirm whether Warp has already planned or scheduled this improvement, so I cannot speak to its roadmap status.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: