GNOME Bugzilla – Bug 722535
Spell checking: highlighting misspelled words slows the search with Ctrl+F
Last modified: 2019-03-23 20:50:38 UTC
I am using gedit version 3.10.3 on a Fedora 20 Linux 64bit box. I noticed that when I open the Search dialog in gedit if I do a search for a phrase in a large document gedit will become unresponsive for some seconds before letting me finish typing the phrase I am searching for. Also the automatic count displayed in the search field of the number of times a particular phrase has been found seems to make this worse. I don't remember older versions of gedit having this problem, they would just highlight words and not get unresponsive when searching.
Does your document contain long lines? If you enable the wrapping, a long line takes for example 5 lines. The search scans blocks of 100 lines. If one block contains lots of long lines, it can take more time. A smarter solution would be to adapt the block size with the number of characters.
Between each block, the search entry should be responsive, so it doesn't matter if you have a large document. What matters is the length of the lines. And if you have another process taking all the CPU resources, it can also block the UI in gedit. So another solution would be to measure the time, and stop the search in the block if the time exceeds e.g. 0.2 seconds.
I've tested the search with 100 lines of 2000 characters. The search entry is less responsive, it takes approximately between 0.1 and 0.3 seconds to scan the block. There is also a known problem with contiguous matches. If you have lots of contiguous matches (1000 contiguous matches for example), gedit can freeze during a long time. Note that the newline characters generally breaks the contiguity, if you don't search for "\n".
With a little more investigation, it seems that getting the current occurrence position can take some time if there are a lot of previous matches. Terry, can you give the occurrence position and the total number of occurrences, as displayed in the search entry, e.g. "1337 of 4242".
Created attachment 266796 [details] html document I am experiencing slow down with
Hi Sebastien, I have attached the document that is giving me slow downs. I have line wrapped turned on with default font size and font, on a fedora 20 box. I did a find for the word "tickable" and it took several seconds to become responsive, if I type it into the search field quickly. If I type it slowly character for character it can take a second or so for each character the occourance values were 1 of 13. I am on a screen resolution of 1600x900 and I have the document windows taking half that horizontal resolution, and I have another document open on the other half of the same screen. Please let me know if there are other things you need to know. I am a bit out of practice when it comes to reporting bugs on bugzilla.
I don't have any problem here. Except if I'm towards the end of the document and search for "t", it can take some time to count the number of previous matches, since there are lots of "t". But with two characters, no problem, the text entry is responsive. Maybe your CPU is overloaded? Take a look at the load average (with htop for example). Since it is a 64 bits system, I guess it is a quite powerful computer. So it is strange that the search is slow for you.
I did the htop test when searching for "tickable" took about 4 seconds and one of my cores showed 100% utilization when the search was happening (and gedit was unresponsive). I have 4 cores and nothing else was slow or unresponsive (windows can be moved, others things update etc.) When not doing a gedit search the htop is on average: Core 1 11.2% Core 2 7.2% Core 3 4.6 Core 4 4.5 Memory 2gig of 8 used swap 0 Tasks 105, 295 Load Average: 0.61 0.53 0.51 One things I didn't mention was that I was doing the search from the very top of the document (my text cursor was positioned there).
When typing "tickable", does gedit freeze between each character? Does gedit freeze also with the search and replace (in the menu: Search -> Replace...)? It is not a search-as-you-type behavior, and the "3 of 10" is not displayed. Try by search for "t" only, and then for "tickable", to see if there is a difference.
With Ctrl+F yes each character has a delay of about maybe 1 and a half seconds. When using Search and Replace to find t it highlights all matching characters in roughly one second. Clicking Replace replaces them one by one almost instantly, and using replaces all replaces them all in about 1 second. Search and replacing the word tickable also results in the same behaviour as above.
Do you use gedit plugins? If yes, try the search when all plugins are disabled. It is possible that a plugin does a synchronous task when the search highlights the matches.
With all the plugins disabled search speed goes back to normal (almost instant). I set about finding out which plugins was causing this issue and it seems to be the spellchecker that comes with gedit on fedora. As far as I can remember I used the spellchecker on Fedora 19 and it didn't slow things down (but I could be dismembering). I checked the Spell Checker about plugin button it showed the following info: Copyright © 2002-2005 Paolo Maggi
Thanks for all the information. I can now reproduce the bug. With the spell checking plugin, the misspelled words must be highlighted in the document. I will see if I can fix that in the spell plugin.
(In reply to comment #13) > Thanks for all the information. I can now reproduce the bug. With the spell > checking plugin, the misspelled words must be highlighted in the document. > > I will see if I can fix that in the spell plugin. Excellent thanks for all the help :)
Created attachment 266925 [details] [review] SearchContext: do not emit the highlight-updated signal I don't really know the purpose of the signal... The spell gedit plugin connects to this signal to update the misspelled words highlighting. When the search sent this signal, all the buffer was rescanned each time, so there were performances problems.
In gedit 3.8, there was the search-highlight-updated signal, that GeditView connects to call gtk_widget_queue_draw_area(). I don't know why it is needed. https://git.gnome.org/browse/gedit/tree/gedit/gedit-view.c?h=gnome-3-8#n100 The GtkSourceView class do the same for the highlight-updated signal. The SearchContext (without the above patch) doesn't send the signal at the right time I think.
Fixed: https://git.gnome.org/browse/gtksourceview/commit/?id=3f0fe75f6b47a881022c9f9f3c2d98fde86b58a3