tags:

views:

945

answers:

2

Hi all,

I noticed a very interesting finding. I was testing my application involving a custom made GUI element which was being updated by data coming from an external source. The update of GUI was done using a slot(Qt specific detail) function whenever data arrived on serial port. Now the data was coming a rate of 10 packets a second i.e the update GUI function was being called 10 packets a second. This had the effect of slowing down the application in addition to constantly increasing its memory footprint. It started at 60 MB and increased to 65 MB in a couple of hours.

My conclusion was that updating the GUI is slow and when a slot for updating is called 10 times a second, the slot calls are queued in the long run thus degrading application response time.

I solved this problem by caching the incoming value and updating the GUI on when there is change in the incoming value.

I have tried various free tools like valgrind-memcheck, leak checker but there results aren't helpful, in fact leak checker doesn't find the leak but my programs memory size is increasing constantly. Does that mean it is because of queuing of signal slot connection as GUI update is inherently slow?

Now here lies the issue. Tracking down memory leaks is hard enough and if Qt is involved how can a hapless programmer be sure of the problem i.e if its actually a memory leak or queuing of signal slot connections?

A: 

Does that mean it is because of queuing of signal slot connection as GUI update is inherently slow?

Yes ...

Stop the incomming events and your memory must be released after a while.

TimW
@TimIn Qt we have only one GUI thread per application. Now if we club the handling of data acquisition with this thread for an external device interface, would this lead to steady increase in memory size or not? Because I am facing such a scenario in an application not developed by my team. An external device interface is clubbed with the main GUI thread. The main GUI also updates when other external devices send data in addition to the device interface which is piggybacking on it. I suspect this design to be the culprit but haven't find a reliable source to corroborate my point
rocknroll
Is it a direct or queued signal slot connection?
TimW
I haven't changed default signal slot settings till now, so it is the default setting (which I don't know about, may be it is queued connections).
rocknroll
Only queued events will build up. Leave your application running for a day it will probably still consume 65MBytes and from the moment that your incomming events stop, the memory will come down.
TimW
+1  A: 

The memory may be fragmented. AFAIK memory is only given back to the OS iff it is page aligned and a multiple of a page size. Some memory allocators don't ever give memory back, googles malloc comes to mind.

So if Qt or your app constantly mallocs and frees small blocks of randomly different sizes, the memory may be kept. The increase of the memory footprint should slow down over time though.

If you are updating some QWidget like object, make sure to use update() and not repaint().

drhirsch