08-16-2019, 08:12 AM
Hi Soren,
I'm not sure how you are logging this data and how you are dealing with creation/destruction of your forms, but I don't think there is any memory leak, unless there is something unusual going on.
Any IW application destroys all owned forms and this has been extensively tested in all scenarios.
If you create an OnDestroy event for your forms and put a breakpoint on them I'm certain that you will see that they are being destroyed.
If you are somehow unable to recreate it, please send me your test application source code (with no external/3rd party dependencies) and I'll check what is happening.
BTW, Task manager is a terrible way to check memory consumption of your application.
FastMM4, the built-in memory manager used by all Delphi applications by default, won't return any allocated memory to the OS (in case of medium and small allocation blocks - which are usually almost all memory allocated by your application), unless the OS requests it.
From FastMM4 readme.txt:
"In an object oriented programming language like Delphi, most memory allocations and frees are usually for small objects. In practical tests with various Delphi applications it was found that, on average, over 99% of all memory operations involve blocks"
Meaning that FastMM 4, in practice, never returns any allocated memory to the OS, because it is *expensive*. Once allocated it is much better to keep it in its own pool and use it again. Again, the OS can still reclaim this memory back, and FastMM will return it back.
Usually, the allocated memory grows linearly up to a certain point and then gets stable. This "point" varies from application to application but can be easily seen in a stress test.
I'm not sure how you are logging this data and how you are dealing with creation/destruction of your forms, but I don't think there is any memory leak, unless there is something unusual going on.
Any IW application destroys all owned forms and this has been extensively tested in all scenarios.
If you create an OnDestroy event for your forms and put a breakpoint on them I'm certain that you will see that they are being destroyed.
If you are somehow unable to recreate it, please send me your test application source code (with no external/3rd party dependencies) and I'll check what is happening.
BTW, Task manager is a terrible way to check memory consumption of your application.
FastMM4, the built-in memory manager used by all Delphi applications by default, won't return any allocated memory to the OS (in case of medium and small allocation blocks - which are usually almost all memory allocated by your application), unless the OS requests it.
From FastMM4 readme.txt:
"In an object oriented programming language like Delphi, most memory allocations and frees are usually for small objects. In practical tests with various Delphi applications it was found that, on average, over 99% of all memory operations involve blocks"
Meaning that FastMM 4, in practice, never returns any allocated memory to the OS, because it is *expensive*. Once allocated it is much better to keep it in its own pool and use it again. Again, the OS can still reclaim this memory back, and FastMM will return it back.
Usually, the allocated memory grows linearly up to a certain point and then gets stable. This "point" varies from application to application but can be easily seen in a stress test.