Nominate our 2022 Qt Champions!

Minimizing window to tray will not lower the memory used!

  • 12.2 Mb when window is not minimized


    12.1 Mb when window is hidden and minimized to tray


    5.9 Mb when program started from an argument that doesn't show the GUI


    So how can we achive 5.9 when the user minimizes the window to tray?

  • Moderators

    You would have to delete all the GUI objects. Normally they remain untouched - only the visibility changes.

  • u mean
    delete ui->addbutton;
    and so on at all the 100 widgets that we have in the mainwindow?

    I just need to add here that all the widgets that are on the mainwindow are in a stackedwidget... but deleting it, will "The program has unexpectedly finished."...

  • If you'll make

    @delete ui->button;@

    than after restoring of window you should make something like this

    @ui->button = new QPushButton;@

    or do not call delete <bla-bla-bla>;

  • Moderators

    As Aleksey noted.

    Personally, I would not bother. It would take you a lot of time to make it all work flawlessly, while most users can afford that 5MB of RAM for your app...

  • ... and even if you do the operating system (or the system library) most probably will not bother reclaiming that small amount of memory, which nullifies the effect completely.

  • Well u know wallch takes 12 mb when u haven't loaded anything.. if i add some items to the listwidget i have in the mainwindow, the memory raises to 31 mb..


    that means it's not a 5 mb difference its a 25 mb difference..

  • You still can't force the OS to reclaim that memory, or even make Qt give it back. For example, the memory of Qt containers isn't returned to the OS but kept for subsequent (re-)allocations. STL containers behave the same, it's a (reasonable) design choice, and there's nothing you can do about it.

    You're worrying about 0.4% of most users' ram. While I generally encourage responsible handling of your users' resources, I'm sure there are more important things to work on in your application than this.

    Still, let me discuss my proposal:
    Don't go the way to delete your UI elements, it won't work. By this you will introduce masses of bugs and instability. Apart from the already mentioned problem of non-effective memory deallocation.
    Rather split your application in two: One low-resource daemon, and one GUI application. The daemon is a background process which handles the background changing. If the user wants to configure something, he starts the GUI which communicates with the daemon. If he's done, he closes the configuration program, which then really frees all that GUI-Memory. This is the only sensible approach I see for such an application.

  • Well, not quite true about the containers. QVector has a squeeze() method to free up unused memory.

Log in to reply