Qt Application Slowing Down

[JonB]

@swansorter
To find memory leaks, before you go down the valgrind or similar route, which is great but a bit intimidating. If you suspect that your leaks are from Qt GUI elements (which sounds like the case here?), you can get to see some really useful potential offenders by leveraging QtWidgets.QApplication.allWidgets() in your code, calling it at useful stages.

I wrote the following for my code (Python/PyQt, but you can easily translate to C++):

def debugWidgetsInUse():
    # Function to allow to see what widgets are currently existing/in use from Qt
    # This can be used to help to detect if there are any "leaks"

    allWidgets = QtWidgets.QApplication.allWidgets()
    errfunctions.uiLogger.debug("Existing widgets: {}".format(len(allWidgets)))

    allDialogs = [w for w in allWidgets if isinstance(w, QtWidgets.QDialog)]
    for dlg in allDialogs:
        errfunctions.uiLogger.debug("Existing dialog: {} ({}) ({})".format(
            str(type(dlg)), dlg.windowTitle(), "visible" if dlg.isVisible() else "invisible"))

    allOrphans = [
        w for w in allWidgets
        if w.parent() is None
        and not isinstance(w, QtWidgets.QDesktopWidget)
        and not isinstance(w, QtWidgets.QMainWindow)
    ]
    for w in allOrphans:
        text = w.objectName()
        if text == "":
            if hasattr(w, "text"):
                text = w.text()
        descendants = [
            descendant for descendant in allWidgets
            if descendant != w and w.isAncestorOf(descendant)
        ]
        errfunctions.uiLogger.debug("Orphan widget: {} ({}) ({} descendant(s))".format(
            str(type(w)), text, len(descendants)))

I call this from time to time (e.g. after any window/dialog closure), and it has allowed me to easily spot a whole class of leaks.

It would be great if Qt allowed you to walk its QObjects list, not just its QWidgets list, but it doesn't provide access to that, so you can only spot widget leaks. But I can say this simple approach has allowed me to easily spot GUI leaks, which may be (at least part of) what you might want to look for....

[mrjj]

@swansorter
Hi.
Did you check all code?
All the dialogs etc
Also do you use new inside the dialogs ?

[swansorter]

@mrjj yess am using new inside dialogs also

[swansorter]

valgrind output

[Christian Ehrlicher]

First please don't post screenshots!
Second as you can see there are 4GB of allocated memory. So it looks like you're allocating memory but forgot to delete them somewhere.

[mrjj]

Hi
Do you use any images in your app ? load them etc ?
Not icons but huge images or similar ?
To use 4GB you have to have something a bit heavy as
clicking back and forth to leak that much using only widgets seems
to would take a long time.
You have to look over all places again and try to guess where it is not assigned a parent
and/or not flagged for delete on close.

[swansorter]

@mrjj yess am using 12kb size image

[mrjj]

Hi
ok that's not so much.
look for new in loop and such places.

How fast does it take to get "slow" ?

[swansorter]

@mrjj within 5 min it starts getting slow
once i got to main window application works normal speed for another 5 min
and again if i back and forth the some other dialog it become slower

[mrjj]

@swansorter
Ok. That's pretty fast.
Does seems related to navigating the app.
I would set breakpoints in all dialogs destructors to make sure they are deleted.
and generally, look over the code verify that you free stuff.

[SGaist]

Hi,

From the look of the code you posted, you are re-creating at least your main window each time you call your settings dialog. If you do that with all your dialogs and maybe other widgets, it's not really surprising that the memory gets eaten up.

You should take a look at the more complex Qt example on how to handle a QMainWindow with one or more dialogs.

Still based on your code and ve fact that you are using images, how are you handling them ?

[swansorter]

@SGaist i searched but found nothing ...
please share the link of any Qt example program

[Christian Ehrlicher]

@swansorter said in Qt Application Slowing Down:

please share the link of any Qt example program

https://doc.qt.io/qt-5/examples-widgets.html

[swansorter]

@Christian-Ehrlicher i need example like QMainWindow with two or more dialogs.

[SGaist]

Having two dialogs or one doesn't change things much.

What do you search exactly with an example with two dialogs ?

[swansorter]

@SGaist yea...qt dialog with more than two dialog

[jsulm]

@swansorter If you can create one dialog you can create 2 or 3 or 4 or ...
So, what exactly is the problem?

[swansorter]

@jsulm 1. we have different screens like home screen ,setting screen ,main sort screen , resort1 ,resort2 and resort 3 screens
2.On "home screen" we have setting button.
3.we move to the "setting screen" with code like the following:-

settingDialog *sd=new settingDialog(this);
sd->setModal(true);
close(); //closes the home window
sd->setAttribute( Qt::WA_DeleteOnClose);
sd->exec();//shows the setting screen

4.On "Setting screen" we have main sort screen Button ,resort1 ,2 ,3 screen buttons to move respective screens.

5.we move to the "main sort screen" with code like the following:-

mainSortDialog *ms=new mainSortDialog();
ms->setModal(true);
ms->setAttribute ( Qt::WA_DeleteOnClose, true );
this->close();//closes the setting screen
ms->exec();//shows the main sort window

6.on "main sort screen" we have Back button to go back to "setting screen".

7. we move to the "main sort screen" with code like the following:-

   sd=new settingDialog();
   sd->setAttribute ( Qt::WA_DeleteOnClose, true );
   sd->setModal(true);
   this->close();//closes the main sort screen
   sd->exec();//shows the setting screen

8.if i do the step 5 and 7 continuously the application gets slower .

[jsulm]

@swansorter said in Qt Application Slowing Down:

if i do the step 5 and 7 continuously the application gets slower

Then you have to investigate.
Did you check CPU usage of your app?
Did you check RAM usage of your app?

[mrjj]

Hi
Also did you CHECK that your dialogs are in fact - deleted?
By breakpoints in their destructors.
WA_DeleteOnClose should take care of that but its good to check.