Re: big cpu consumption
On Tue, 19 Aug 2008, EJP wrote:
Tom Anderson wrote:
That's what we call a busy-wait
No it's not.
Well, actually it is, although it's waiting for a condition which will
never occur.
I don't understand this statement. A blocking operation isn't a
busy-wait by any definition.
That's certainly true.
My take, having read what jolz posted, on what's happening is that the
read method is returning -1 because the hasn't started the line. Thus,
he's in a busy-wait.
You know what? I'm going to actually run this program.
[time passes]
Okay, after adding in definitions for the variables which were missing,
and altering it to use an audio format which my machine supports, i have a
program which compiles and runs. I have instrumented it to print out
numBytesRead and the size of the ByteArrayOutputStream buffer (which is
the number of bytes in the buffer, not its capacity) every time it goes
round the read loop.
The results:
read returns 0, and the buffer never contains more than 0 bytes.
So, if the OP's situation is the same as mine, the OP was wrong about the
break being where the CPU is consumed, you were wrong about this method
call blocking, and i was wrong about, er, well, all sorts of things,
actually. Rather, what's happening is that there is a busy-wait, but based
on the read call returning 0 immediately and thus leading to nothing much
happening in the rest of the loop.
Oddly enough, this is sort of what i thought was happening in the first
place, hence my comment about a busy-wait. But i'd misread the code - i
thought the test that leads to the break was testing for 0. So i was sort
of right in a wrong way.
Anyway, someone who was right was jolz: if you call line.start() before
the loop, data comes out, the buffer fills up, and on my machine, the
program never consumes more than 5% CPU.
The annoying thing is that this behaviour isn't documented: the javadoc
actually says nothing about the what happens if the line hasn't been
started, and doesn't specify what happens if the method is called after
the line has been closed and all pending data has been read. The other
annoying thing is that the behaviour is to return 0, rather than throwing
an exception.
The OP may well be showing 80% CPU but I suggest that if it was a
busy-wait it would have been 100%.
When i run the buggy program (with the printing commented out), its CPU
use hovers between 50% and 70%. I'm also running Firefox, with about a
million tabs open, so maybe that's using the rest. I would guess something
similar applies on the OP's machine.
tom
--
1 pWN 3v3Ry+h1n G!!!1