Feature Request: Add delayed search trigger in main window to prevent UI freeze with large tabs

Is your feature request related to a problem? Please describe.
When there are many items in a tab, typing in the main window to search causes CopyQ to hang or even crash. This happens because the search begins immediately after the first character is typed — which often matches a very large number of entries. As a result, CopyQ starts performing expensive searches repeatedly while the user is still typing, severely impacting performance and responsiveness.

Describe the solution you'd like
Introduce a small delay before the search actually starts after each keystroke — for example, around 100 ms. This would allow the user to type a few characters before CopyQ begins searching, drastically reducing unnecessary intermediate lookups.

An even better approach would be to use a variable delay depending on how many characters have been typed:

~150–200 ms after the first character
~100 ms after the second
~50 ms after the third
No delay (or minimal) after the fourth onward

This way, the UI remains responsive during early typing when search results are the largest and slowest to compute.

I never observed any UI freeze during search, even with large tabs - for me, there seems to be no delay at all (let alone crash!). Maybe something else unrelated to filtering/highlighting the items causes this.

What is the app version and OS?

There is already a 200ms delay to trigger the search on any change of the search text entry.

CopyQ/src/gui/filterlineedit.cpp

Line 361 in cf421b5

m_timerSearch->setInterval(200);

Maybe also related to #3111. I don't think I ever had more than ~20,000 items in a tab.

Improve responsiveness if filtering large tabs

Fixing in #3265.

Improve responsiveness if filtering large tabs

Thanks for taking a look at this! App version and OS at the bottom.

I’m also at 20,000 items in this tab (which I believe is the cap). I noticed the problem gets dramatically worse when some items are very large. To test this I wrote a simple script that removes the 50 largest text items:

copyq:
var itemsToDelete = 50;
var sel = ItemSelection(selectedTab()).selectAll();
var items = sel.items();
var itemSizes = items.map(function(item, index) {
    return {
        index: index,
        size: str(item[mimeText]).length
    };
});

itemSizes.sort(function(a, b) {
    return b.size - a.size;
});

//var largestItemsSel = ItemSelection(selectedTab());
const removed = []
for (var i = 0; i < Math.min(itemsToDelete, itemSizes.length); i++) {
    removed.push(itemSizes[i].size)
    remove(itemSizes[i].index);
}
const totalKb = Math.floor(removed.reduce((a, b) => a + b, 0) / 1024);
popup(`Removed ${itemsToDelete} items with a total of: ${totalKb} Kbytes`);
//largestItemsSel.removeAll();

Running this once immediately solved the “crashes” (technically the app becomes unresponsive, gnome flags it as ANR, and it recovers after a couple of minutes). Running it a few more times made search reasonably responsive again.

For context, I frequently copy&paste megabyte-sized text blobs, and search has always struggled to me. I only opened the issue now because it became unusable this time.

Before clearing the large items, I also tried adding a small input delay and rebuilding CopyQ like I suggested, although I did it at MainWindow::onFilterChanged.
This solved the ANR, but it didn’t really reduce the UI freeze after the search begins nearly as much as removing the largest items did.

Maybe my initial thought is wrong and the root cause could be related to handling and/or reordering very large entries rather than just the search debouncing? I’ll run a few more tests when I have time and report back if I find anything else. If you want me to perform any specific tests or get gather any other info just let me know.

Thanks again for providing such a great application to the community! 🙏

@esauvisky

@esauvisky Thanks for sharing the details. Not sure why the crash would happen. I thought it could be the system getting out of memory, but filtering does not increase the memory usage (the large items are not kept in memory unless needed). Maybe it is just a problem with processing some Qt events very late after the UI is unblocked.

Improve responsiveness if filtering large tabs

@hluk

@hluk works very well now, it no longer blocks the UI! great job! ❤️

@hluk

@hluk this is just fantastic. thank you so much for this improvement. Works flawlesly 🚀

Navigation Menu

Repository navigation

Feature Request: Add delayed search trigger in main window to prevent UI freeze with large tabs #3261

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Feature Request: Add delayed search trigger in main window to prevent UI freeze with large tabs #3261

Description

Activity

hluk commented on Oct 18, 2025

hluk commented on Oct 18, 2025

hluk commented on Oct 18, 2025

esauvisky commented on Oct 18, 2025

hluk commented on Oct 19, 2025

esauvisky commented on Oct 20, 2025

executed commented on Nov 9, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions