Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 110154

Summary: vte 0.11.x is slow
Product: [Fedora] Fedora Reporter: Peter Zelezny <peterzelezny>
Component: vteAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 1CC: barryn, cioby, cmurtaugh, lsof, mitr, rickrich
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:00:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter Zelezny 2003-11-15 14:09:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030 Galeon/1.3.10

Description of problem:
After noticing slow compile times, I tracked it down to vte. It's
actually taking alot of time rendering what gcc spits out. The hit is
pretty substantial. Using a test of "time rpm -qa", I got these results:

xterm: 3.6 seconds
xterm with FreeType font (AA): 4.5 seconds
rxvt: 3.6 seconds
vte-0.11.10-4: 11.3 seconds
linux console: 3.1 seconds

Obviously vte is doing alot (UTF-8, AA et al.), but I believe vte
0.10.x did much better than this.


Version-Release number of selected component (if applicable):
vte-0.11.10-4

How reproducible:
Always

Steps to Reproduce:
1. Open gnome-terminal
2. time rpm -qa
3. watch it scroll for too long.


Additional info:

Comment 1 Dumitru Ciobarcianu 2004-02-06 06:44:45 UTC
Confirming on big compiles. 
vte takes time to render all the text he has in the queue.

Afair if xterm has a long display queue it just "skip" to the current
output. That makes sense?


Comment 2 Thomas M Steenholdt 2004-07-01 20:38:08 UTC
This bug is valid for core 2 as well... and very annoyoing too!

I've seen it discussed on bugzilla.gnome.org but no real solution
seems to have come out of any of it!

to me this bug is important to get fixed... I frequently do some
programming in vi under a gnome-terminal (or at least i would, had it
performed properly) but scrolling up/down is just to painfully slow,
when browsing the code for instance.

please update severity as this effectively renders gnome-terminal
useless. Also, please bump version to devel, as the problem is stille
not fixed.

Comment 3 Havoc Pennington 2004-07-03 11:31:06 UTC
It doesn't make gnome-terminal useless, thousands of people use it
daily. Having a bug open for "make things faster" is not really useful
since it isn't a specific well-defined task, and bugzilla is a task
tracker; really the bug we need open is "the following function shows
up in a profile and can be optimized in the following way" Lots of vte
optimization has been done, what fixes are still possible is an open
question.

We have accelerated the RENDER extension in X.org server, which should
make a big difference.



Comment 4 Need Real Name 2004-10-18 06:53:34 UTC
gnome-terminal isn't useless, but it is really slow.

xterm
real    0m19.997s

gnome-terminal
real    3m54.364s

Comment 5 Need Real Name 2004-10-18 06:54:22 UTC
*** Bug 135672 has been marked as a duplicate of this bug. ***

Comment 6 Ray Strode [halfline] 2004-11-04 05:26:09 UTC
*** Bug 75478 has been marked as a duplicate of this bug. ***

Comment 7 Rick Richardson 2004-11-04 06:25:33 UTC
Havoc, this bug has existed in gnome-terminal ever since RH8.  The
gnome-terminal in RH 7.2 did not have this problem. xterm has never
had this problem.

Accelerating the RENDER extension in the X.org server is NOT an
acceptable fix.  Expecting newer, faster hardware to cover up sloppy
programming and/or design is the Microsoft way, and that way has no
business in our world nor in the attitude of one of the leaders in our
world.

Comment 8 Ray Strode [halfline] 2004-11-04 06:48:39 UTC
Hi Rick,

The "vte is slow" problem is a problem that is being addressed.  There
are a number of performance patches out there that are being looked at
and added (see bug 132770 for instance).

Comment 9 Need Real Name 2004-11-04 08:24:25 UTC
bug 132770 says the speedup patch is in rawhide..
A cached "find /" on xterm is *ludicrously* faster.

Also, xterm doesn't have the weird "page up" ghosting bug when viewing
a text file with less.

Comment 10 Warren Togami 2004-11-16 02:14:18 UTC

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

Comment 11 Red Hat Bugzilla 2006-02-21 19:00:01 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.