Well, the 0.11.14 release only contained crash fixes so I don't think we're
going to back them out again just to increase performance again. The only thing
you changed between these runs was the vte version?

Yep, that's the only component changed. As mentioned, downgrading to 0.11.13
brings back the performance I've been used to with gnome-terminal in FC4. Can't
say I've got super-hardware, but still.. The terminal is a vital app to me, and
I need[want] session-management, tabs and profiles, so my only alternative to
gnome-terminal is Konsole (which is much faster), but I really don't want KDE
stuff on my desktop =).

Another issue (probably mentioned many times before in other bug reports) is
that even though gnome-terminal is minimized/unexposed, it has the full
potential of making the rest of my X desktop very unresponsive if it runs a
command that produces a lot of output (hexdumping a large file, for instance).
This also seems worse after the 0.11.14 update. With gnome-terminal[vte] being
one of the slowest terminal emulators around (but still very nice,
feature-wise!), I think performance regressions in recent updates deserves
attention.

Do you by any chance have accessibility turned on? I found that this made quite
an impact on the terminal performance here...

(In reply to comment #4)
> Do you by any chance have accessibility turned on? I found that this made quite
> an impact on the terminal performance here...
Nope, I have no accessibility components enabled, never had. Let me just stress
that vte-0.11.13 performed well enough for me, and I was very happy that the
performance had increased so much since older times (gnome-2.6). But vte-0.11.14
brings it down a bit too much. Also, I never had any crashes with gnome-terminal
and vte-0.11.13.

The performance might not be a problem for people with newer machines. But with
my hardware, vte-0.11.14 is sluggish in full-screen, while 0.11.13 is not,
regardless of accessibilty setting or font (bitmap or anti-aliased true-type).
That's why I noticed it in the first place, it was a very visible difference.
 
(I did recompile pango and vte with specific optimizations for my own CPU and
`-fomit-frame-pointer'. But that only shaved off about half-a-second, relative
to a plain i386 redhat build (same test as above), so it's insignificant (as
expected).)

Let me know if more info or testing is needed, I'd be happy to help in any way I
can.

The only way to find out which of the fixes in 0.11.14 broke this is to apply
them one at a time: bug 169326, bug 119913, bug 126262, bug 311570 and one
change that I can't find in bugzilla:

diff -u -p -r1.422 -r1.423
--- vte.c       11 Jun 2005 21:05:07 -0000      1.422
+++ vte.c       7 Jul 2005 19:00:21 -0000       1.423
@@ -16,7 +16,7 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */

-#ident "$Id: vte.c,v 1.422 2005/06/11 21:05:07 kmaraas Exp $"
+#ident "$Id: vte.c,v 1.423 2005/07/07 19:00:21 matthiasc Exp $"

 #include "../config.h"

@@ -11759,11 +11759,13 @@ vte_terminal_unrealize(GtkWidget *widget

        /* Unmap the widget if it hasn't been already. */
        if (GTK_WIDGET_MAPPED(widget)) {
+
                gtk_widget_unmap(widget);
        }

        /* Remove the GDK window. */
        if (widget->window != NULL) {
+               gdk_window_set_user_data(widget->window, NULL);
                gdk_window_destroy(widget->window);
                widget->window = NULL;
        }


If you could find out which of these broke it for you that would be *great*.

I meant either revert them from 0.11.14 or apply them one at a time to 0.11.13
of course :-)

I've gone through all those patches and tested. None of them causes the
performance to drop. However, I've identified another difference between 0.11.13
and 0.11.14 which _does_ cause the performance to drop (and which looks MUCH
more related to scrolling/repainting):

[oyvind@gandalf tmp]$ diff -u vte-0.11.13/src/vte.c vte-0.11.14/src/vte.c
--- vte-0.11.13/src/vte.c       2005-03-14 15:43:47.000000000 +0100
+++ vte-0.11.14/src/vte.c       2005-07-25 10:46:12.000000000 +0200
<SNIP>
@@ -690,7 +690,6 @@
 vte_terminal_scroll_region(VteTerminal *terminal,
                           long row, glong count, glong delta)
 {
-       gboolean repaint = TRUE;
        glong height;

        if ((delta == 0) || (count == 0)) {
@@ -698,41 +697,15 @@
                return;
        }

-       /* We only do this if we're scrolling the entire window. */
-       if (!terminal->pvt->screen->scrolling_restricted &&
-           !terminal->pvt->bg_transparent &&
-           (terminal->pvt->bg_pixbuf == NULL) &&
-           (terminal->pvt->bg_file == NULL) &&
-           (row == terminal->pvt->screen->scroll_delta) &&
-           (count == terminal->row_count) &&
-           (terminal->pvt->scroll_lock_count == 0)) {
-               height = terminal->char_height;
-               gdk_window_scroll((GTK_WIDGET(terminal))->window,
-                                 0, delta * height);
-               if (delta > 0) {
-                       vte_invalidate_cells(terminal,
-                                            0, terminal->column_count,
-                                            row, delta);
-               } else {
-                       vte_invalidate_cells(terminal,
-                                            0, terminal->column_count,
-                                            row + terminal->row_count + delta,
-                                            -delta);
-               }
-               repaint = FALSE;
-       }
-
-       if (repaint) {
-               if (terminal->pvt->scroll_background) {
-                       /* We have to repaint the entire window. */
-                       vte_invalidate_all(terminal);
-               } else {
-                       /* We have to repaint the area which is to be
-                        * scrolled. */
-                       vte_invalidate_cells(terminal,
-                                            0, terminal->column_count,
-                                            row, count);
-               }
+       if (terminal->pvt->scroll_background) {
+               /* We have to repaint the entire window. */
+               vte_invalidate_all(terminal);
+       } else {
+               /* We have to repaint the area which is to be
+                * scrolled. */
+               vte_invalidate_cells(terminal,
+                                    0, terminal->column_count,
+                                    row, count);
        }
 }
<SNIP>

When this is applied to 0.11.13, the performance drops.

I hope this will be some help.

Øyvind

Ah, thanks for tracking that down. This is from bug 164153 and is a fix for some
scrolling problems. Egmont, is there no way to avoid the performance hit when
fixing the scrolling issues?

In bug 164153 I state that I know about the small performance regression at
generic use of vte. I'd call a 29s -> 35s a small regression. However, in the
mean time, this patch fixes dozens of things described in that bugreport and
in other bugreports linked there. For example, in bug 156935 a case is
described where execution time reduces from 28 seconds to below 1 sec. That one
is more important I guess than 29 vs 35.

Obviously I'd be happy to see the old performance back in a way that the
dozens of issues fixed by this patch still remain fixed. However, I do not
have a solution for this. Personnaly, I think that all of the issues of
bug 164153 are more important than a 29 vs 35 seconds. YMMV. Unfortunately I
do not have time to work on patches that are not important to me, I have plenty
of other (not Gnome related) jobs to do. So I'd let other people do it. But
please don't revert this patch without fully understanding and fixing in
another way all the issues fixed by this one.

Good luck people, and Oyvinst please apologize me :-) and see what you gain by
this patch. E.g. try PageUp's in less with old and new vte...

Well, I understand. I knew it fixed the less-scrolling thing, and all. Well, if
I was more familiar with Gnome/GTK I'd have given it a shot, but I am also
pressed for time=). The patch removes logic which only conditionally repaints (I
guess in a previous attempt to speed things up) ? Now it repaints everything all
the time ? That's explains it, at least. I just need a working term on my
machine, that's all. Right now it's not usable for me in full-screen
[1280x1024]. But since it fixes some important stuff, I guess it needs to stay.
It's a little bit frustrating, though, to see Konsole so much faster, because I
like Gnome :(. Well, anyway, thanks to all to responded to the bug-report.

Should this bug be closed with WONTFIX ?

I think it's worth keeping it open so we can investigate potential ways to
reenable the optimization without the issues it created previously.

I don't think keeping this open is going to buys us anything... We already choped like 70% of the time by a single optimization somewhere else.