GNOME Bugzilla – Bug 756086
Ctrl+F search takes around 2 minutes(!) if a long line is present
Last modified: 2020-11-24 09:57:59 UTC
Created attachment 312683 [details] Test file for triggering the bug CTRL+F search for "_init" takes around 2 minutes(!) in attached test file. Considering that the file isn't that large, this seems like something that should be addressed. Steps to reproduce: 1. Open gedit 2. Paste the test file contents into a new document 3. Press CTRL+F 4. Type: _init Now gedit will hang about 2 minutes before responding again.
Have you read: https://wiki.gnome.org/Apps/Gedit/ReportingBugs ? Frequent Bugs -> Very long lines Did you reach the gedit bugzilla via a direct link? If yes, where? I would be interested to know, so we can maybe change the link so that it points to the wiki page instead. *** This bug has been marked as a duplicate of bug 127731 ***
I do not think we should close this as a dupe right away. The line is not that long and does not hang gedit in general and it is "find" that it is slow... We should at least try to profile it and make sure it is not something the the matching code
Hi Sébastien, I filed the bug because Paolo suggested in chat this might be worth looking into as a possibly separate issue to the "regular" long lines thing. I wouldn't know myself, I'm just a user :-)
The line contains 18000 characters. The syntax highlighting more or less works with the attached file, even if editing the text is slower than in Plain Text (there is around 1 second of freeze). So yes, the search and replace should also be usable. With the Find and Replace dialog, searching "_init" doesn't freeze gedit. The freeze happens because when typing "_" in the search-as-you-type box, it searches for a single character, so lots of tags are added. I wrote this branch some time ago: https://git.gnome.org/browse/gedit/log/?h=wip/search-timeout Having a timeout for the first characters would make this bug harder to trigger. But it's probably not sufficient.
Another thing i noticed is that gedit freezes for even longger when second character is typed. type '_' (freezes for sometime) type 'i' after that (feezes for way longer) type 'n' after that (instant) remove 'n' (instant) remove 'i' (freezes for sometime) so going from first highly occuring character to sencond character takes even longer time than the single character. Also, the problem occurs even if search highliting is turned off. (because all the occurances are found anyways to show the count) If optimizing the search for long lines is very difficult. Can we have a limit, in case of long lines, after which gedit just says "1 of Many" and don't highlight the results. It won't be ideal, but anything is better than freezing up and potionaly losing work in current or other opened documents.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.