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?
You would have to delete all the GUI objects. Normally they remain untouched - only the visibility changes.
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."...
AlekseyOk last edited by
If you'll make
than after restoring of window you should make something like this
@ui->button = new QPushButton;@
or do not call delete <bla-bla-bla>;
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...
lgeyer last edited by
... 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..
DerManu last edited by
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.
Asperamanca last edited by
Well, not quite true about the containers. QVector has a squeeze() method to free up unused memory.