GNOME Bugzilla – Bug 325853
search and replace hangs (or runs much to long)
Last modified: 2013-07-13 10:30:56 UTC
Distribution: Unknown Package: gedit Severity: Normal Version: GNOME2.12.0 2.12.x Gnome-Distributor: SUSE Synopsis: search and replace hangs (or runs much to long) Bugzilla-Product: gedit Bugzilla-Component: general Bugzilla-Version: 2.12.x Description: Description of Problem: replace text in a large XML-file (6.1 MByte) hangs (run more than 20 minutes) Steps to reproduce the problem: 1. open replace dialog 2. enter text to replacing 3. the cpu load raise to 100% and nothing happens Actual Results: nothing will replaced, editor must killed with kill command Expected Results: text will be replaced How often does this happen? Additional Information: ------- Bug created by bug-buddy at 2006-01-05 12:41 -------
Hello, I've been said this issue was known on the 2.12 version, and was resolved in the development version. Could you provide your XML file gunzipped? and so I will test it with the version 2.13. I need to know also what pattern did you replace. Thanks you
Created attachment 56815 [details] XML-File to reproduce this bug The search pattern is not important. I could reproduce this bug with various patterns.
I wanted to know how many item the function ahd to replace (like ten, or a thousand). thanks
I tried to replace "Track Number" by "track number" and I had the same behaviour so confirming. I don't know if it useful but I have a stacktrace
+ Trace 64975
Thread 1 (Thread -1225701152 (LWP 7336))
Baptiste: Stack traces are not useful in this cases. Could you please try to gather some profiling information using sysprof (http://live.gnome.org/Sysprof)? Thanks for you help.
I tried to replace more than thousand items to replace. (In reply to comment #3) > I wanted to know how many item the function ahd to replace (like ten, or a > thousand). > > thanks >
The problem is that gtksourceview spends a shitload of time rehighlighting the text because it does it for every delete and insert (that is twice for every match!) If you turn off highlighting (for instance choosing Edit->Highlight Mode->Normal) the replace all is fairly fast (at least on 2.13... on 2.12 it will be not really fast but way shorter than 20 mins!)
Created attachment 58694 [details] [review] patch to disable bracket-matching during replace-all I've been seeing this too, so I did a bit of profiling. With cvs HEAD, I'm seeing ~70% of the time being spent in gtk_source_buffer_delete_range, most of which is because gtk_source_buffer_move_cursor is doing bracket-matching to highlight matching brackets. Doing this during the middle of the replace operation seems a bit silly. This patch disables the bracket-matching during replace-all operations. For the file I tested, this reduced the time from about 10 minutes to 3, a significant part of which was redoing the layout (which takes a fair while on startup for this file). Whether there are any negative side-effects that need to be worked around, such as having to do the bracket-matching a single time once it's finished, I'm not sure.
For the testcase provided above, this doesn't seem to make much difference. As noted above all the time seems to be spent redong the highlighting and the replace becomes pretty fast when the highlighting is turned off. On the other hand the patch makes perfect sense and you say that there are cases where it matters. With regard to side effects: the bracket matching should be reevaluated when the feature is turned back on... this doesn't happen at the moment, but it's a gtksourceview bug. Patch applied.
Created attachment 58923 [details] [review] disable search-highlight during replace-all This turns off search-highliting during the operation, which provide another speed boost. For the file I have been testing against, the remaining profile is 45% pango and 50% utf8 stuff (match case was off).
Patch committed to cvs.
You said 45% of time is spent in Pango. Is this true also when syntax highlighting is disabled? Does the undo manager play some role too? May be we should try to "freeze" syntax highlighting when running replace all. Do you see some way for optiming the UTF-8 stuff too?
As discussed with James on irc, I don't like the idea of freezing the highlighting very much. At least until we are positive that it's a real bottleneck and not just a bug. In particular see http://bugzilla.gnome.org/show_bug.cgi?id=330406 which was filed in realation to some further investigations. If (and only if) we really need a way to explicitely freeze the HL from the caller, it should only freeze the 'batch processing', that is the exposed part of the buffer should still be highlighted so that the user scrolls the view he stills sees the highlighting.
*** Bug 369442 has been marked as a duplicate of this bug. ***
Search and replace is still slow in 2.30.3. Tried the steps described here https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/45174 and gEdit stopped responding for a few seconds, without any progress indication.
Fixed with the async search API in GtkSourceView.