GNOME Bugzilla – Bug 484615
gedit consumes 100% processor with paragraphs > 10 lines.
Last modified: 2016-11-26 16:53:16 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/145400 "Binary package hint: gedit There is a problem with gedit (or maybe even the gtksourcebuffer widget) when editing long lines with syntax highlighting. Ive seen bug #134352, and it seems to be similar to what I am reporting here, but I am creating a new bug report since in the original report the problem seems to be minor since only long one-liner html files seem to be the issue. However, this bug appears even when doing a short document (for example your homework) on Latex, and writing a small paragraph (less than 10 lines) without using line breaks. To reproduce, create a new latex file and open it in gedit, make sure gedit correctly detects it as latex file and it is doing syntax highlighting on it. Now start typing gibberish (ie. asdf asdf asdf asdf asdfasdf asdf), as your paragraph continues and the buffer starts to break your line into several lines, you will notice how the processor consumption will start going up, by the time you reach 10 break lines or so (at least on my machine) the processor will reach 100% usage. I think this bug is pretty serious, since having a 10line paragraph seems a pretty common use case for a text editor. ... http://launchpadlibrarian.net/9527057/bug-example.tex latex example for gedit bug (1.0 KiB, text/x-tex) I am using gutsy with the latest updates, an attached example follows, to reproduce the bug, just go to the end of the garbage line and start appending your own garbage :) ... gedit still hangs for me, yesterday updates no helps! gedit (2.20.0-0ubuntu1) to 2.20.1-0ubuntu2 gedit-common (2.20.0-0ubuntu1) to 2.20.1-0ubuntu2 I can't edit any .sql document that gedit consumes 100% cpu. :-/ ..."
mmm... I cannot reproduce this. When the CPU usage goes up does gedit hang? or does it just get sluggish?
it get slightly sluggish, I think I would not really notice if that was not for the CPU monitor jumping to 100% while typing
I can reproduce this. I'm also running gutsy beta with the latest updates. I reach 100% CPU and it becomes very sluggish on my 4th or 5th line of latex markup.
distro bug comments "I can confirm it happens only with text wrapping on.. disabling wrapping no issue at all! > Does it happen without syntax highlighting? I.e. take the same text, put it into a file which isn't highlighted at all (some plain text document), and see if you have the problem. ok.. tested with a 500kb .sql document: Highlight on+wrap on=disaster, 5-10 secs of full hanging Highlight on+wrap off=seems usable, cpu sometimes rise highlight off+wrap off=works like a charm... well i'd like to use highlight and wrapping as well :-) I hope these tests can help you debugging."
I am not sure why I do not get this... any chance you guys could run sysprof and show us a profile?
What about "highlight off + wrap on"?
I did some testing using sysprof. looks like the code is hitting a slow cairo or driver path similar to what is described on https://bugs.freedesktop.org/show_bug.cgi?id=4320, most of the time is spent in cairo, pango and xorg. With only wrapping on typing is not really laggy but the CPU usage still goes to 100%. Opening gedit and starting to type some text sends the CPU usage to around 40% on my desktop (athlon 3000+ cpu) which is really a high consomation for standard text typing. Entering text in other applications doesn't create a similar CPU load so that's not likely a GTK bug
We are screwed. gtk_text_buffer_remove_tag() forces recalculating the paragraph. And we remove all tags (all tags known to the engine) from a region when highlighting is recalculated: so even in the case when there are no highlighting tags in the paragraph, the engine forces recalculating the pango layout.
I have that freedesktop.org 4320 bug, and in my case gedit spends more time in the X server and libfb than in Gedit itself...
(In reply to comment #7) > I did some testing using sysprof. looks like the code is hitting a slow cairo > or driver path similar to what is described on > https://bugs.freedesktop.org/show_bug.cgi?id=4320, most of the time is spent in > cairo, pango and xorg. With only wrapping on typing is not really laggy but the > CPU usage still goes to 100%. Sebastien, could you post the profile? And also profile the case of simple textview, without any highlighting (CPU usage goes up in that case too, just not as much). Please make sure you have some 20-30-40 lines in the paragraph, so the slowdown is more visible. (In reply to comment #9) > I have that freedesktop.org 4320 bug, and in my case gedit spends more time in > the X server and libfb than in Gedit itself... Federico, can you reproduce the bug if you apply the workaround from that f.d.o. bug? Sysprof tells me it's layout recalculation, and my numbers seem to agree with this - two recalculations are much worse than one which is already slow (and I don't see drawing stuff in profile at all). Maybe I have a lucky video card, but there certainly is a bug apart from cairo being-cool-and-good, and that bug might be possible to fix in gtksourceview.
Can we close it now, after http://bugzilla.gnome.org/show_bug.cgi?id=494776 is fixed?
*** Bug 498718 has been marked as a duplicate of this bug. ***
Can you still reproduce this?
Actually, the situation has probably got better, but the problem is still there. When reporting the (dup) bug #498718, I gave as example the text (13, 12), (14, 12), (16, 12), (22, 12), (25, 12), (27, 12), (30, 12), (33, 12), (35, 13), (38, 13), (40, 14), (42, 14), (44, 14), (46, 15), (48, 15), repeated (with no newlines) 7-8 times, and I said it rendered gedit unusable. Now, with 7-8 times it's OK, but the problem is still here if we go to 20+ lines. From the tests I made, I would make a guess that the time needed to move up/down with the cursor increases linearly with the number of lines, and that the improvements made to gedit since the first report of the bug at most decreased this time only by some (multiplicative) constant. I'm not expert in syntax highlighting computational problems, but - certainly we can parse scripts at least at the same speed we can execute them, which is, in this case, very fast - even if we had a very efficient syntax parsing, I see no reason why a non-edit operation such as moving up/down the cursor should require a time which increases with the lenght of the paragraph: seems like currently just colors - and not the syntax tree - are kept in memory... So I'd say the bug is not solved.
Thanks for taking the time to report this. However, you are using a version that is too old and not supported anymore by GNOME developers. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes by GNOME developers for the version that you use. CPU consumption seems normal with big LaTeX lines with Gedit 3.22.0. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug report if the problem still occurs with a recent version of GNOME, or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.