Re: [Gnash-dev] fix cpu burning before code freeze?

[John Gilmore]

> Can anyone think of anything critical that should be fixed before the
> code freeze ?

The one thing I've been hoping to get to (but haven't) is whatever
makes gnash burn up massive CPU time when the flash movie is idling.
E.g.  in youtube after finishing playing a movie.  Yes, there's little
stuff going on, moving thumbnails around every few seconds, but we
shouldn't be burning up a whole CPU to do it.

If it's something easy, let's fix it; if it's something hard, let's
at least start to understand it.

When gnash is in that state, top shows 100% cpu utilization of one core.
There are 5 threads.  All are running, doing system calls, according to
strace.  I did "strace -p 6519 -f -ff -o gnash.idle" and got five files
of syscalls, one per thread.  I interrupted it after about 10.3 seconds
(measured by the gettimeofday results in the files).

The lowest numbered thread (6519) is doing endless gettimeofday()
calls, more than 17,000 in my 10-second sample, plus an occasional
read(3) getting EAGAIN followed by polling fd's 4 and 3 for input,
with a ZERO timeout!  (Maybe that timeout should be longer?)

Thread 6525 is doing nanosleep({0, 100000}, NULL) = 0 continuously.
Never doing any other system calls.  Why is its sleep so short (100K
nanoseconds, or 100 microseconds, or 0.1 milliseconds = waking up 10,000
times/second)?

Thread 6527 is doing something repetitive; it writes "x" to fd 11,
polls fd's 12 and 14, gets input on 12, sends a 20-byte binary packet
on 14, reads a "W" from 12, polls again (awakened by output on 14),
sends a 16-byte packet on 14, polls again (awakened by output on 14),
does clock_gettime twice, polls again for input only (awakened by
input on 14), receives a 20-byte message on 14, repeats this
poll/receive loop three times, then writes an "x" to fd 11 and starts
over.  It also did more than 7000 clock_gettime calls and 1700 futex
calls during my 10-second sample.

Thread 6528 appears to be the other side of this mysterious
communication; it's writing "W"s to fd 13 and reading "x"s from fd 10,
and other than its almost 3000 futex() calls and a poll awaiting input
on fd 10, it behaves nicely (its poll is with infinite timeout).

Thread 6529 is sending and receiving HTTP protocol on fd 23, getting
JPEG files and writing them into files in /tmp, but is also doing
short-timeout select() and poll() calls (select {0,10000} and poll 0).
Bizarrely, the select() calls has no file descriptors selected, so it
always waits; but as soon as the process wakes up from it, it does a
zero-timeout poll() call on fd 23.  Pushing these two together to
select() on fd 23 might eliminate the need for short timeouts in both
calls.  It also did 204 clock_gettime calls in my 10-second sample.

Perhaps just adjusting the timeouts in our select and poll calls will
eliminate the useless burning of CPU time.  The other obvious
performance question is whether we need all the gettimeofday() and
futex() calls that we're doing.

        John