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 157049 - GtkTextView *extremely* slow on very long lines
GtkTextView *extremely* slow on very long lines
Status: RESOLVED DUPLICATE of bug 134682
Product: gedit
Classification: Applications
Component: general
2.4.x
Other Linux
: Normal normal
: ---
Assigned To: Gedit maintainers
gedit QA volunteers
Depends on:
Blocks:
 
 
Reported: 2004-11-01 16:57 UTC by Olivier Sessink
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Olivier Sessink 2004-11-01 16:57:10 UTC 
loading a 11kB file (with only 3 newlines!!) in Bluefish (a gtk text editor,
using the GtkTextView widget) is extremely slow. After enabling some profiling
in the Bluefish syntax highlighting, it turned out that setting 1992 tags
(GtkTextTag) takes 143 seconds. If I add some newlines to that same file, and
load it again, the syntax highlighting needs < 0.1 seconds to set the same 1992
tags. That is a 100X difference, and just caused by lack of newlines.

I tested this using gtk 2.4.13.
Comment 1 Owen Taylor 2004-11-01 18:31:06 UTC 
Making a non-gridded text widget efficient for extremely long lines
is a really hard problem that we have little idea of how to solve.

Using non-linear structures like skip lists in GTK+ and Pango
to store individual paragraphs would help a lot ... but if you
read the GtkTextView or Pango code, you'll see that the code
is already pretty darn tricky without that.

I think gedit needs to check and guard against such files... at
least ask the user if they really want to load it and warn that
performance may be extremely bad.
Comment 2 Matthew Gatto 2004-11-02 01:49:31 UTC 

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