100% CPU load

[kartun]

I started development on Debian 5.0.7, and now switched to Ubuntu 10.10. Qt installed 4.7.1.

I'm using Qextserialport and after OS switch I found 100% cpu load. I checked with gprof and found this :


Flat profile:

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
60.00 0.06 0.06 QextSerialPort::qt_metacall(QMetaObject::Call, int, void**)
40.00 0.10 0.04 QextSerialPort::qt_metacast(char const*)
0.00 0.10 0.00 8642 0.00 0.00 QByteArray::size() const
0.00 0.10 0.00 4850 0.00 0.00 qt_noop()
0.00 0.10 0.00 4502 0.00 0.00 QByteArray::at(int) const
0.00 0.10 0.00 1069 0.00 0.00 QBasicAtomicInt::deref()
0.00 0.10 0.00 885 0.00 0.00 QString::~QString()

Where to look and how to track the problem ?

[mcosta]

please, post your code

[kartun]

here is the main loop :

void PortListener::tryReceive(){
if(this->port->bytesAvailable()>0){
timeout = qMax(100, timeout/2);
// Thread unsafe block. Lock it
qDebug() << "And 1";
lock.lockForWrite();
myRcvBuffer.clear();
myRcvBuffer.append(port->readAll());
qDebug() << "bytes read:" << myRcvBuffer.length();
qDebug() << "bytes:" << myRcvBuffer;
last_packet = Hemofenix_protocol::decode_packet(myRcvBuffer);
lock.unlock();
emit packet_received(last_packet);
} else {
timeout = qMin(1000, timeout*2);
}
QTimer::singleShot(timeout, this, SLOT(tryReceive()));
}
For some reason this event fires only on mousemove/keypress. Any ideas how to debug that ?

[mcosta]

I have some observations.

you should check if there are enough byte to read.

instead of use QTimer::singleShot, use a QTimer instance and use setInterval and start.
The static function creates a new connection at each call

[SixDegrees]

Also, you should be sure you actually have a problem in the first place. How are you measuring CPU usage? Are you sure the measurement is accurate? And what does it mean to say that the CPU is 100% active? CPUs only have one speed; they're either working or they're not, and if they are they're 100% busy.

Are you seeing an actual slowdown in your application or in the system as a whole? If not, what is it youi're trying to improve?

Note that all CPU measurement tools are inaccurate, and can measure very different things. The Windows performance monitor, for example, is notorious for giving essentially meaningless readings.

[wysota]

CPUs only have one speed; they're either working or they're not, and if they are they're 100% busy.
That's not entirely accurate, they can run at different frequencies. And 100% for each frequency means a different load. So measuring percentages makes no sense. 100% cpu usage means the task is the only one occupying the cpu, it doesn't mean it is "saturating" the CPU as as SixDegrees noted the CPU is always saturated (or idle).

[tbscope]

The percentage usually means the amount of instructions the processor handles at a given time interval with respect to the maximum it can perform in that time interval.

Saying that the processor is either 100% idle or 100% busy is like saying that the chance of winning a lottery is 50%, you either win it, or you don't :-)

[SixDegrees]

The percentage usually means the amount of instructions the processor handles at a given time interval with respect to the maximum it can perform in that time interval.

Saying that the processor is either 100% idle or 100% busy is like saying that the chance of winning a lottery is 50%, you either win it, or you don't :-)

True, but that's exactly the problem: sampling. How measurements like this are counted makes them vary widely, and without further information they are nearly useless. They certainly don't measure program efficiency in any way; when your process has the CPU, it has 100% of it. It may get switched out by other processes, but that's related to system load, not the performance of the particular program.

[kartun]

Also, you should be sure you actually have a problem in the first place. How are you measuring CPU usage?
Are you seeing an actual slowdown in your application or in the system as a whole? If not, what is it youi're trying to improve?

yes, I'm 100% sure. I've several keyboard handlers in the app, and without this loop response to keypress is immediate, but when this loop is running I've like 1.5 sec delay.
I'm using standart gnome system monitor, and when this loop is active CPU load jumps to 100%, and after it stops it comes back to 0%.

Added after 53 minutes:

Seems I found a problem, may be it would help someone ...
I was using

this->port = new QextSerialPort(portName, QextSerialPort::EventDriven); as it was suggested in included "PortListener" example. I switched to

this->port = new QextSerialPort(portName, QextSerialPort::Polling);
and CPU usage dropped to expected 2-3%.

I tested it on Ubuntu 10.10 (2.6.35-25-generic #44-Ubuntu SMP) and Debian 5.0.7 (2.6.29 with Vortex86DX patch)

p.s. Using QTimer member instead of static QTimer::singleShot doesn't give any noticable difference. And thanks to everyone who tried to help :)