[linux-audio-user] gnome-terminal performance

John Check j4strngs at bitless.net
Sat Jul 31 22:21:31 EDT 2004


On Saturday 31 July 2004 05:19 pm, Lee Revell wrote:
> On Sat, 2004-07-31 at 16:09, Florin Andrei wrote:
> > On Sat, 2004-07-31 at 12:57, Chris Pickett wrote:
> > > note that i don't like menubars or scrollbars or any of that crap, and
> > > aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
> > > shift+up/dn).
> >
> > Actually, gnome-terminal is good from a usability p.o.v. I like the way
> > it has copy/paste keyb shortcuts, i actually use the Reset And Clear
> > function (makes it easy to copy/paste huge swaths of text), etc.
> > But, with JACK needing a smooth environment, gnome-terminal seems like a
> > timed bomb. :-(
>
> You *have* to use realtime scheduling if you want jackd to work.
> Period.  Otherwise, the system is doing exactly what you are telling it
> to.  You have two processes, gnome-terminal and jackd, with the same
> priority, so when both of them want to run, it's 50/50 who will get
> scheduled.  It is *not* gnome-terminal's fault if scrolling text causes
> XRUNs in jackd.
>
> If jackd were running SCHED_FIFO aka realtime, and gnome-terminal as a
> normal priority process, it would be a bug (priority inversion) if
> gnome-terminal *ever* interfered with jackd's operation.
>
> <rant>
>
> BTW it is trivial to demonstrate that gnome-terminal does in fact have
> major performance problems.  Running 'top' in a maximized gnome-terminal
> on a PII-450, the gnome-terminal process takes something like 20% of the
> CPU.  Just to redraw a screen full of text once per second.  When a
> program performs *that* much worse than another one for no good reason,
> it is called a performance BUG.
>
> I am surprised no one has mentioned the real reason gnome-terminal is
> such a CPU hog - font anti-aliasing.  The GNOME people say this needs to
> be hardware accelerated for decent performance, and that none of the
> current video drivers do this.  However, Windows does the same thing on
> the same machine WAY faster.  So either the Linux video drivers are
> buggy, or Windows has a 100x faster way to anti-alias fonts.
>
> I think the distros made the wrong choice in putting anti-aliasing into
> their desktops before it was ready.  I am supposed to be impressed
> because the desktop *finally* looks halfway decent compared to Windows,
> except *way* slower?
>
> I cannot believe the GNOME developers would respond to the original
> complaint with 'hey, don't bug us about performance, we're still adding
> FEATURES over here!  it's not really a problem, and if it is, you need a
> faster machine'.  At least *pretend* to be interested in reining in the
> bloat.
>

Oh man...  B-b-b-b-b-ut they just eliminated features! 

> Can't they understand that I do not want gnome-terminal on my 3Ghz
> machine to be about as fast as xterm on a P133?  I bought a faster
> machine because I want it to do basically the SAME stuff as the old one
> but FASTER, and with a few more features!  Have you tried a
> pre-anti-aliasing distro lately, like RH 7.3?  It SMOKES!  *Way*
> snappier than today's equivalent.
>

This list isn't the place for it, but... If I was a ranking gnome developer... 
and I was employed by XYZ... Which happens to be a big company with a vested 
interest in gnome/linux... I might make some decisions that... were in tune 
with company policy.. Not because it was my job.... but I'd still have office 
politics to contend with because I'd want to keep said job. 
One has to acknowledge at least the possibility of that sort of thing 
affecting ones evaluation of the world. They are only human. The attitudes at 
the top filter down to everybody else.

Whatever works is my credo.

> Here is the main point they seem to miss:  If I upgrade from a circa
> 2000 machine (hardware and software) to a 2004, I expect the latter to
> be significantly faster *AND* address the limitations of the old
> software.  In no circumstances should it be slower, or even the same - I
> just UPGRADED, remember?
>
> </rant>
>
> Lee



More information about the Linux-audio-user mailing list