gedit consumes 100% processor with paragraphs > 10 lines.

Bug #145400 reported by Alex Cornejo on 2007-09-26
62
This bug affects 10 people
Affects Status Importance Assigned to Milestone
gedit
Expired
Medium
gedit (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

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.

Sebastien Bacher (seb128) wrote :

Thank you for your bug. What version of Ubuntu do you use? Could you attach an example?

Changed in gedit:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Alex Cornejo (acornejoc) wrote :

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 :)

Alex Cornejo (acornejoc) wrote :

Keep in mind that if you have an uber monitor with a 1920x1200 resolution, maybe the example I posted will not create a 7 line paragraph, so please resize your window so that the attached example produces a few line breaks (6 seem to be enough to get my 2.2ghz machine to its knees).

This happens to me too.. I'm using gutsy beta from scratch!

Alex Cornejo (acornejoc) wrote :

I am confirming this bug since another user reported the same problem (seb: I hope I'm not screwing the status up again :( )

Changed in gedit:
status: Incomplete → Confirmed

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. :-/

Dzamir (dzamirro) wrote :

Happens to me too, using gutsy beta with latest updates.

Sebastien Bacher (seb128) wrote :

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=484615

Changed in gedit:
status: Confirmed → Triaged
Changed in gedit:
status: Unknown → New
muntyan (muntyan) wrote :

Guys, who can reproduce this, could you confirm it happens only with syntax highlighting turned on? Because syntax highlighting may very well be slow reason, but then it should be slow regardless if you use text wrapping or not. E.g. some comments here sound like it's re-wrapping text which is slow, others sound like it's highlighting.

I can confirm it happens only with text wrapping on.. disabling wrapping no issue at all!

muntyan (muntyan) wrote :

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.

Luca

Paolo Borelli (pborelli) wrote :

What about highlight off+wrap on?

right.. i've forgotten that combination! :)
highlight off+wrap on = it's ok... pretty scrollable and editable. (seems equal to highlight off+wrap off)
so, in my opinion, "highlight" is our issue...
i'm ready, if necessary, to continue testing gedit.. bye!

Luca Forina

Sebastien Bacher (seb128) wrote :

What videocard and driver do people getting this issue use?

Nvidia GeForce 7600 GT 256mb PCI-Ex
nvidia-glx-new 100.14.19 + 2.6.22.4-14.8
(athlon 64, 1 gb ram, gutsy i386)
I get the same with and without compiz enabled.

Alex Cornejo (acornejoc) wrote :

I have the same reports as to highlight/wrap combinations as Luca.

About the videocard, on the two computers I've tested it on I have different video cards,

one of them is an nvidia geforce 7400 GO, with the nvidia-new drivers (latest)

The other has an old ati rage something, and I am using the r128 driver of Xorg.

I don't have any special insight into what exactly is causing this bug, but I doubt it is a driver issue (otherwise we would have problems with openoffice, mozilla, etc.. etc..).

I am pretty sure it has something to do with highlight engine+wrapping, maybe as we enter new text in gedit the new margins for wrapping are recalculated, and the highlighting of the whole line gets recalculated. Since some highlighting engines use a lot of regexp for detecting different highlight regions, this could potentially trigger regexps over the whole line for each new character inserted. Anyway, this is just a wild theory since I have no clue about the inner workings of gtksoruceview or pango (which I guess could also be part of the problem).

Regards,
Alex

muntyan (muntyan) wrote :

Good, now the picture is much more clear. I guess the problem is that the engine removes/applies tags and that makes re-wrapping harder (text styles change text width/height, so it's worse than simple text with no styles at all).
If anyone feels like playing with it, profiling would be of great help: sysprof will do well here (you need gtksourceview built with debuggin symbols, like described here: http://live.gnome.org/GettingTraces)

Alex Cornejo (acornejoc) wrote :

Ok, I'm in midterms right now, but as soon as I have some time I will profile gedit. Out of curiosity muntyan, do you experience the same problem that we describe or are you unable to reproduce this behavior? A simple test is to try adding garbage text (ie. asdf asdf...) to the example I posted on this bug report.

Your processor usage should be adversely affected if you keep typing garbage repeatedly.

muntyan (muntyan) wrote :

Yes, new engine eats a lot more cpu time here. Some 50-60% in top vs 12% with no highlighting. Scratching head time!

muntyan (muntyan) wrote :

It must be much better after fix for http://bugzilla.gnome.org/show_bug.cgi?id=494776, which should be in the next version of Gtk.

Changed in gedit:
importance: Unknown → Medium
status: New → Confirmed
Kris (kristian-holsheimer) wrote :

This bug is still present in ubuntu 13.10 (gedit version 3.8.3).

Not reproducible with gedit in Trusty.

Changed in gedit (Ubuntu):
status: Triaged → Invalid
Changed in gedit:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.