How to minimize memory usage in runtime
-
The reason as Volker mentioned.
I think that you should do something after minimized your app.
1> Try to free all the objects what have you created and not used after minimized your app;
2> Try to free the memory which not used after minimized your app. -
But keep in mind that you must recreate the destroyed objects (not necessarily QObjects!) as soon as you show the window again. And if the objects are important to your application, you will have to save their state in one way or the other, which might be expensive or time consuming too. Also, it's annoying for the user, if he has to wait too long for the application to be restored on the screen in case you have to "wake" it up.
-
But most of the time deleting something won't return all the memory to the OS(Windows).
For example, I create a dialog which needs 14M. I can release 5M after delete it. I know that the 9M will be used again if I create something. But shouldn't the 9M memory return to OS when I minimize my app?Another problem I found is qt apps are consuming more and more memory... I'm working on Windows7. First is my app, at start-up, it takes 22M. After some time, it will grow to 50M, even if I don't "new" anything.
Then I found QtCreator is sort of like that. At first it takes 106M, than after amount of time, it grows to 203M. Although if I close the project, I can get back 30M. The point is the total memory usage is climbing up. I'm really frustrated about this problem. -
[quote author="Morris" date="1287935248"]Then I found QtCreator is sort of like that. At first it takes 106M, than after amount of time, it grows to 203M. Although if I close the project, I can get back 30M. The point is the total memory usage is climbing up. I'm really frustrated about this problem.[/quote]
This memory will get freed later when required. I do not see much cause of concern here ... Does the usage continue to grow to say 300-400...eventually 700-800 MB or further? Then you might have a leak, which eventually will cause it to crash.
-
It is up to the C runtime (on which C++ relies on most systems) to return memory back to the OS. If the heap is fragmented there might be not enough continuous memory at the end that can be freed and returned. So, depending on the application and library logic, it's likely that you do not have a classical memory leak in your code and your objects are destroyed, yet memory consumption is still increasing over time. There's hardly any solution to this problem, despite quitting and restarting the program.
-
Morris: How do you measure the memory usage? Tools like the task manager in windows are not up to the task. Better use tools like valgrind (Linux, I do not know of a good tool for windows).
-
[quote author="chetankjain" date="1287937912"]So, in the end, will the app crash in such a scenario or ... ?[/quote]
Not necessarily. In such a scenario the increase of memory cunsumption is usually very slow, as the memory manager still has plenty of unused memory on the heap that can be reallocated. For further details one should use tools like valgrind, as Tobias mentioned. There's always a possibility of real memory leaks - even in the Qt libs themselves ;-)
If the memory consumption eventually stalls at a certain level, I'd leave it for that.
BTW: The memory allocation on Windows is a bit weird, as each DLL has it's own memory management, AFAIK. That adds even more complexity to this topic.
-
[quote author="Tobias Hunger" date="1287937783"]Morris: How do you measure the memory usage? Tools like the task manager in windows are not up to the task. Better use tools like valgrind (Linux, I do not know of a good tool for windows).[/quote]
I'm using process explorer(the data it provides is pretty the same as windows 7 task manager's). It's better than the one in WinXp. Though it won't tell me how much RAM exactly does my app consume, but it provides a clue. And the users won't be satisfied if they read the high memory usage from the task manager.[quote author="chetankjain" date="1287937912"][quote author="Volker" date="1287937574"]There's hardly any solution to this problem, despite quitting and restarting the program.[/quote]
So, in the end, will the app crash in such a scenario or ... ?[/quote]
It's hard to make it crash this way, because you have so much memory. I'm not sure if is because heap fragmented. But at least I have check my code with Virtual Leak Detector, which tells me there's no leak(at least not in my code).[quote author="chetankjain" date="1287938069"]bq.
I do not know of a good tool for windowsI've used Rational Purify on win32. But I continue to seek out and ask others for more tools on windows ... :([/quote]
I couldn't get Rational Purify to work. Is there any example? -
Same problem:
a simple mainwindow with a pushbutton. When I run the "not-doing-anything program" for several minutes the private and shared physical memory of the programm rises some kb's. My OS is WinXP and I didn't get a Rational Purify license yet,so I use the "ProcessExplorer" of Microsoft Sysinternals instead. I don't know how reliable this tool is, but I encountered that at programm startup the private memory is at a certain level. When I minimize the programm, the private memory drops to very low, when I maximize it again the private memory rises but to only half the size as it was at program startup.
Is this just the tool or what could it be?I have to build an application that runs several months without stopping so even slowly rising memory usage of the program could be fatal.
Any suggestions?
-
mr_gui: Get yourself a good memory profiling tool.
-
[quote author="mr_gui" date="1290688722"]I have to build an application that runs several months without stopping so even slowly rising memory usage of the program could be fatal.[/quote]
I have experience with qt3-based graphics applications that run more than 6 months on Windows XP. The memory usage is increased nearly 5 times from original (10 - 50M) but system reacts quickly.
If the application is running on Windows and uses custom dlls then look on utility rebase, it allows to specify the base address of the dll library. Specifying non-overlapping base address for all libraries significantly reduces physical memory usage. It is good optimization without code re-factoring :)
Also think about splitting the tray-indicator and main application in 2 independent processes, if it is possible. And start main process when it is requested from the tray icon.