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/ _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
