Hide\Show or Delete\Construct?

[Kryzon]

For a Qt application that the developer is trying to spare as much system memory as possible, is there any significant benefit in controlling the visibility of a widget by deleting and constructing it, as opposed to using hide() and show()?

The choice of deleting it instead of hiding it would be in the sense of releasing the system resources for the widget when it's not visible, so it doesn't remain allocated.

[jefftee]

It totally depends of course. If it's needed frequently, I'd hide/show it and if infrequently, then it should be acceptable to new/delete, etc.

[Kryzon]

Thank you for the reply. I didn't know if using new\delete was an acceptable approach with Qt.

I hadn't thought of taking the widget lifetime in consideration, it's a clearer perspective. Most of the widgets are embedded in docks that the user arranges in the layout that they want, but once the docks are set the user will most likely keep the same layout for a long time.
Therefore I can delete the widgets in the docks that are hidden, and recreate them when the user requests the hidden docks.

[jefftee]

After hearing your use case, I would probably just hide/show the widget as needed. Unless your widget's memory usage is extreme of course. I have been pleasantly surprised at the overall memory footprint of my Qt applications. For such a large library, you'd think it would be much more of a memory hog, but I have not found that to be the case in practice.

Good luck.

[d_stranz]

Therefore I can delete the widgets in the docks that are hidden, and recreate them when the user requests the hidden docks.

The average QWidget instance uses negligible memory in comparison to the memory used by other data structures in a typical program. Unless you are running on a device with extremely limited memory, trying to optimize by creating and destroying widgets on demand is pretty much a waste of effort. What that approach is more likely to do is to actually end up using more memory because of heap fragmentation.

If the heap doesn't contain a contiguous region big enough to accommodate a request to create an object instance, it will grow (usually by far more than the amount needed) so the new object can be created. The only time the heap can be compacted is when an object is deleted that allows two adjacent unallocated regions to be combined. Existing objects can't be moved around, because that would change their pointer values.

So it doesn't make much sense under ordinary conditions to delete an object if you know you'll probably create it again later, especially if it is a unique object like a widget that's part of your GUI.

[Kryzon]

That's interesting, I didn't know about heap fragmentation.

At the start of the program I'll know what widgets are needed: it's either a default set of widgets, or a user set from QSettings from the last time that the program was used.
Therefore it's possible to only allocate widgets that are visible at the start of the program. As the user opens new widgets they will be allocated on demand. If a widget gets closed, it's hidden and remains allocated.

The difference here would be the loading of only a partial amount of widgets at the start of the program (the same widgets when the program was last closed), instead of all of them.
The goal is to have a lightweight program, but I'll check the memory footprint of having all of the widgets allocated; it might not be that much.

[Radek]

Kryzon, you are optimizing at a wrong place. Can you imagine, how much memory gets occupied when all needed Qt DLLs get loaded? The memory occupied by your windows is negligible with respect to it so that saving space here is wasted time and wasted effort. Either you have enough memory or your optimizing cannot save you. Linking statically won't help: the Qt code get linked to your exe and you end with a huge exe which won't get visibly smaller by experimenting with repeated creation or simple hiding/showing.

The only situation when you can optimize something consists in having a Qt based desktop (for example, Linux KDE). The DLLs are already in use (the desktop uses them) so that your app will link to them and the DLLs won't be loaded again. Even then, you would need to link with your desktop version of Qt (in Debian Wheezy, it is Qt 4.8.2) and not with contemporary Qt 5.4. Windows desktop isn't Qt based so that launching a Qt based exe = loading the exe along with all needed DLLs. At least, qtcore, qtgui, and if your exe uses other Qt modules then other Qt DLLs, too. Even with a Qt desktop you won't save much: a typical Qt executable of a small program is several hundered of kB.

Therefore, optimizing the code would mean leaving Qt and remaking the exe so that it will use your "native" DLLs - commctl32, commdlg32 (or what they are called today) and so on and without any interfaces making the programmer's life easier. In fact, rewriting the Qt app from scratch. You would get a completely unportable app which would be small only on your current windows and nowhere else.

IMO, it's not worth it. Therefore, cleanse the app and hide/show your windows (it's simpler than create/delete repeatedly and it does not fragment memory). You cannot do much more.

[Kryzon]

Point taken, thank you for the information.