I can also reproduce, but does this impact any real use case?
Do I need to explain in more detail or would it be sufficient to say that I use the xfce4-appfinder as a temporary copy/paste box which can be called by a hotkey (Alt-F2), and as it is minimal it minimaly blocks everything else I see on the screen?
Pasting a 1000 characters string freezes appfinder for about one second here, not terrible, cutting is lag-free. If you try to edit it then yeah, appfinder gets really slow, but at this point a simple text editor (vim, mousepad, etc) makes much more sense (I myself use vscode for this very same purpose you mentioned).
With a quick perf run it's possible to see where the CPU struggles the most:
Stop filtering after a certain number of characters, e.g. 80.
Debounce input, unfortunately gtk doesn't support it ootb, implementing it right™ could be tricky.
Stop filtering when adding characters and search results are already zero, although this solves the slowdown when typing, hammering the backspace key will continue to be sluggish.
Perhaps need to be "turned on" (or off) by choice (or by a command-line switch)?
In any case, shouldn't a user be WARNED NOT to use that for sensitive information as they will be further exposed (traveling along the stack with all those look-ups)?
Or perhaps maybe one should develop a small textbox app, without any filterings that will run with either Alt-F2 or Alt-F3 replacing XFCE's default setup with that being run either xfce4-appfinder --collapsed or xfce4-appfinder?
This issue is caused by the method xfce_appfinder_model_fuzzy_match, which causes another annoying issue that is (with a clean cache) when you try to execute an app in appfinder you have to press Enter 2 times, instead of just once.
I managed to fix both issues with this before building:
sed -i 's/xfce_appfinder_model_fuzzy_match (item->command, string);/strncmp (item->command, string, strlen (string)) == 0;/g' appfinder-model.c