Re: BUG: gnome terminal horrible performance

[Florin Andrei <florin andrei myip org>]

On Fri, 2004-07-30 at 19:07, Ryan McDougall wrote:
> On Thu, 2004-29-07 at 12:07 -0700, Florin Andrei wrote:
> > http://bugzilla.gnome.org/show_bug.cgi?id=148796
> > 
> > Why does gnome-terminal takes so many resources to perform trivial tasks
> > such as scrolling text up?
> 
> Do you have any numbers on how gnome-terminal is a resource hog?

Trying to divide myself between a demanding job, private projects and
family, i don't exactly have much time to spend debugging applications
that i didn't write.

Probably this perpetual haste is a cause for the inflamatory tone of my
original message, for which i apologize.

Anyway, i can give you some help. Here's how to reproduce the problem:

Install JACK and control it with qjackctl. Set it to best performance
settings: real-time priority, etc.
Install LADSPA and a few effects.
Install Ardour (or any other digital track recorder that can use JACK)
and use JACK to capture and record sounds from your soundcard. Add a few
LADSPA effects for good measure.
This is a typical setup for a musician or a sound engineer using Linux.
It's actually a bare-bones, minimalistic setup, so in theory it should
have no performance issues whatsoever.

Now run tail -f in a terminal, watching a log file. Use gnome-terminal
for that, then use xterm.
In both cases, do your best to abuse the system (like, watch a really
chatty log in the terminal and at the same time run a big CPU-hog of a
LADSPA effect), and count the amount of xruns (dropped sound frames) in
JACK.

(For the non-privy: If you're doing "serious" audio/music work, a single
xrun typically means you have to go back and start the session over.)

With xterm, it's very difficult to trigger an xrun on modern hardware
running a decent kernel.
With gnome-terminal, xruns pop up out of blue sky.

The situation is much better if JACK runs with real-time priority and
you're using other options that make it more resilient against xruns,
but it gets rapidly worse if you cannot use real-time for whatever
reason. With gnome-terminal, is not getting worse, it's getting
catastrophical.

I have no numbers, sorry.

There are probably other ways to demonstrate the problem. Audio apps
essentially must meet the "soft realtime" requirement (meaning,
real-time but not strict), so anything else running under similar
conditions will get hit by gnome-terminal.

I suspect even watching videos with Xine or GStreamer or another video
player will get afected by gnome-terminal, but it's probably much more
difficult to tell when a frame got dropped. With JACK, it's really
simple and objective: it logs the xruns, timestamps and all, so you can
count them afterwards.

If you Gnome folks want to make Gnome friendly to multimedia apps, this
bug is probably important.

> The
> numbers return by top/System-monitor/etc are *not* reliable.
> In general
> tracking resource usage requires extensive profiling, and is really non-
> trivial.
> Slowness does not imply resource-hog.

Agree with all of the above.

> > Experiment: Run gnome-terminal and xterm side by side.
> 
> Not a fair comparison since they are not comparable feature wise. Would
> you compare a F1 racer and SUV for racetrack speed?

Again, i agree. But it doesn't seem fair to me that gnome-terminal makes
it impossible to run time-critical apps (audio, music, video) on a Linux
workstation without fear of dropping frames.

And it's such a basic application. It's not like we're talking here
about OpenOffice or Evolution something.

> > Compile an application that makes gcc very verbose in each terminal.
> > With gnome-terminal, the overall system load is significantly higher.
> 
> Once again this may be nothing more than xterm can write ASCII text,
> where gnome-terminal has to print via Pango.

Frankly, i'm a "simple user", i don't care what happens "under the
hood", it's just that this "car" cannot perform a very simple task of
going from point A to point B.
I don't know the reasons for that, and frankly i don't care.

> > Any plans to fix this bug?
> 
> This is not really fair at all.

(Warning: I'm re-enacting a previous state of frustration, just to
describe exactly what happened. But now i'm putting a distance between
it and my current state of mind, and i kindly ask you to do the same.)

"Not fair" were the words crossing my mind when the simple application
that's gnome-terminal caused a JACK xrun that ruined an audio track that
had my best take ever of a certain complicated sequence of notes. I
agree i'm a lousy keyboard player and a newbie, you don't wanna hear me
play unless you enjoy the aesthetics of ugliness :-) but OTOH that's
precisely why i need software that doesn' get in the way, so i don't
waste whatever few chances i get at sounding at least passable.

> The people who are writing our desktops for us for free are very short
> of time

I understand that, and i apologize if i've been too aggressive.

It's just that on one hand i'd like to use Gnome, because overall i find
it the best desktop for Linux, on the other hand simple things like
gnome-terminal eating up too many resources (or whatever, i'm not an
expert) prevent me from completing my projects.

> and implementing new features is a higher priority than
> extensively profiling gnome-terminal for a performance problem

I fear you might be correct.

P.S.: Please use the Reply-To header of the message, don't Cc me.

-- 
Florin Andrei

http://florin.myip.org/