Re: [Audacity-devel] [Audacity-users] Audacity CVS consumes CPU while idle, Fedora 12, x86_64

[Al D. <bus...@gm...>]

On Thursday 01 October 2009 15:34:26 Gale Andrews wrote:
>
> In the first few minutes of Audacity being open, the load is circa 0.3.
> The load value (and the % of CPU use taken by Audacity) then rise
> continually until Audacity is task switched to.
>
> > This could be confirmed using top (hit u and type your username so
> > you only get your processes, hit > until you're sorting
> > by command name, hit R if necessary to reverse sort order and bring
> > audacity into view, then hit H to view each thread separately)... maybe
> > Gnome's system monitor can do this also, I don't know (KDE's doesn't seem
> > to have a thread view).  I see three audacity threads while I have one
> > project open and it's just idling.
>
> All I did was to launch Audacity and it is just sitting there as an
> empty project, but grabbing more and more CPU as time goes on.
>
> After I have pressed "H" in "top", is each line in the display a
> thread? If so, most of the time there is only one Audacity thread
> (occasionally, a second one appears momentarily). The number
> of threads does not increase when Audacity status in System
> Monitor changes to "Running" about the time it starts taking
> half the CPU. Sorry I don't understand the "Sleeping" and "Running"
> distinction in System Monitor, and their "documentation" does not
> help.
>

Yes, after hitting H each line is a thread.  When I filter out other users' 
processes and sort by process name I always see two audacity threads at the 
top of the window... that's not to say that you're wrong, I don't really know 
a lot about what audacity uses threads for.

The difference between sleeping and running is the following: if it's running, 
the program had work that it was ready to do at the precise moment that the 
process monitor polled the process state.  If it's sleeping, the program 
didn't.  Most interactive programs spend most of their time sleeping, waiting 
for input.  When input arrives some other process (perhaps the X server, or a 
terminal emulator in the case of terminal-based programs) sends the program a 
signal.  The program then has to execute its signal handler, so it has work to 
do, so it's in the "running" state.  When the handler finishes it goes back to 
sleep.  Programs can also put themselves to sleep for specific periods of time.  
If you look at the line for "top" in top the S column will always have an R in 
it; that means the state is always "running".  Not because it's always 
running, but because it is always running while it's polling process state.  
Likewise, an S (for sleeping) in that column doesn't mean that the process 
hasn't run at all since the last poll, it just means it wasn't running at the 
time of the poll.

The load average is the average number of threads "running" each time the 
scheduler picks a thread to execute.  I think you generally don't expect one 
thread to increase the load average by much more than 1; certainly one thread 
can only itself account for a load average of 1.

> My user is running 16 threads or so.
>

Huh, mine is running a lot more than that.  Most of them start with k.  You 
probably don't have as much crap installed as I do, and maybe KDE runs more 
separate processes and threads than Gnome does.  I don't seem to remember 
having so many processes/threads going at a time back when I used FVWM.

> If you minimise Audacity and keep it out of view, can you reproduce
> the issue then?

I'm doing this now; I've been running for about 25 minutes and haven't seen 
anything yet.  It very well could have to do with libraries... All my wx 
libraries are 2.8.9.1, according to Synaptic.

 - Al