Use a timer-based search activation algorithm to prevent live search-as-you-type from wrecking performance and locking up gedit on large files
It happens relatively frequently that I make the terrible mistake of opening some big XML or SQL file (ok, not that big; a 700 KB SQL file, for example) and try searching for something in it, then Gedit's ctrl+F search causes the application to lock up entirely, because it tries to immediately trigger a search everytime you type a character, which is stupid (and I say that with absolutely no animosity: I'm saying the same thing about my own software).
This is particularly frustrating because it's not only slow, it also locks up the whole application, and at some point it might un-freeze in 5-10 minutes (during which it hogs your CPU), or you might have to kill it... thus losing any unsaved stuff you had in open text tabs. Users can be losing data because of this, so it's pretty bad.
So what I'm proposing is that, instead of making the search static (i.e. you have to press Enter to launch the search, like in 2.x, or like in Leafpad or), you use a logarithmic timer-based activation technique to avoid spamming your search engine. Basically, the same thing I'm proposing in https://github.com/getting-things-gnome/gtg/issues/281 (which hasn't yet been implemented there, but I've demonstrated this to make a huge difference in performance; check it out, I go into a lot more detail over there). Perhaps in gedit's case you can also make the algorithm more aggressive in its "back-off" behavior when gedit detects the file to be a big file (big filesize, or crazy number of characters on a single line) than when it's a normal/small file.