After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 320991 - Gedit handles lines with too many characters VERY slowly
Gedit handles lines with too many characters VERY slowly
Status: RESOLVED DUPLICATE of bug 114337
Product: gedit
Classification: Applications
Component: general
2.10.x
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
gedit QA volunteers
Depends on:
Blocks:
 
 
Reported: 2005-11-08 17:32 UTC by Michael Carlson
Modified: 2005-11-08 17:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Michael Carlson 2005-11-08 17:32:57 UTC
Please describe the problem:
I have a 14,706 byte file that consists of one line. When I load it in gedit, on
my Athlon XP 1900+, the gedit window behaves noticeably slow (using considerable
CPU) when it needs to redraw the window, and when scrolling up and down. What's
worse, if I try to click to put my cursor somewhere in the document, it is also
very slow. If I click near the beginning of the line, it isn't too bad, but near
the end of the line it can take 2 seconds of 100% cpu usage until it starts
showing a flashing cursor. Clicking and dragging to select some text takes even
more time (sometimes more than 3 seconds), and if you try to switch to gedit
from another program, select all and then copy (which is what I was trying to
do), the delay can be quite long, and it's very annoying.

I understand it's not everyday we edit files with a single line this long; but
it would be nice if the software was robust enough to handle it in a reasonable
speed. I like gedit; don't make me go back to some other editor for these files.
I'm glad it displays everything right and doesn't crash, but it's just way too
slow, it's practically unusable.

Steps to reproduce:
1. Make a file with a large number of characters on one line (mine was 14K)
2. Open it in gedit and try to use gedit normally to edit that file / that line
3. Try: scrolling, clicking to move the cursor, selecting text by clicking and
dragging, hitting "select all", switching to other windows and back to watch the
redrawing speed

Actual results:
gedit reacts very slowly, and whenever you're waiting for gedit to respond
again, my CPU usage meter (which is in my gnome panel) shows 100% usage.
Sometimes it lasts for several seconds, and my CPU isn't ancient (Athlon XP 1900+)

Expected results:
gedit would be just as fast and smooth as it is on other files

Does this happen every time?
Yes

Other information:
I'm using Debian sid. I tried downloading CVS gedit and compiling it, which
resulted in the same problem. I then used oprofile to try to find the offending
functions, but I found that the horrific CPU usage was all in libgtk. This might
not be a gedit bug because of that, but it's also probable gedit is just not
using the GTK api as efficiently as it could, and since I don't know any other
app to test this with, I'm filing it under gedit.
Comment 1 Paolo Borelli 2005-11-08 17:40:39 UTC
Unfortunately this depends from GtkTextView, the gtk+ text widget that gedit
uses and there is no way to fix it (short of deeply changing how it works
internally)

*** This bug has been marked as a duplicate of 114337 ***