[linux-audio-user] gnome-terminal performance

Lee Revell rlrevell at joe-job.com
Sat Jul 31 23:03:00 EDT 2004


On Sat, 2004-07-31 at 22:21, John Check wrote:
> 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:
> > 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!

Really?  Haven't missed them yet...

> 
> > 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.
> 

Yeah, I understand that in the real world no one likes to pay
programmers to make things faster.  "Well, yeah, it's faster, I could
get the same result by just throwing more hardware at it, and it's
cheaper than paying you coders".  From reading the Fedora lists the Red
Hat people were a lot more worried about adding internationalization 
support or whatever than about making it faster - at some point I think
they just decided to hell with performance.  Which makes perfect sense,
when you consider that the slowness is the least of your worries if the
thing does not even speak your language yet.

I do understand Red Hat's motivations - I have to admit I was pretty
impressed at how good FC1 looked the first time I saw it, so much so
that it took me a while to realize how much performance they had to give
up.  That was the first Linux distro that made me thing 'this could
replace windows for 99% of what people do'.  Correctly designed software
will always be significantly slower than the equivalent hack job
(Windows).

Plus you can always count on the speed demons out there fixing
performance problems in your code.  If you wait around for them to
translate it into Urdu... not the greatest business model.

That being said, it kind of looks like they might have papered over the
problem, by increasing the block size and making it consistently
slow-ish.  However it takes the exact same amount of time to do the seq
test every time.  xterm, uxterm, rxvt, urxvt all are very choppy - if
you run the seq test 10 times, it will be blazingly fast a few times (1
sec), but it's usually more like 9-10 secs.  Also, it seems like it's
slow until the first line of your output reaches the the top of the
screen, then the rest is very fast.  None of these are nearly as bad as
gnome-terminal used to be.

Lee
	





More information about the Linux-audio-user mailing list