Memory leaks

develop32 develop32 at gmail.com
Sun Oct 13 07:37:04 PDT 2013


On Sunday, 13 October 2013 at 14:31:13 UTC, Benjamin Thaut wrote:
> Am 13.10.2013 16:23, schrieb develop32:
>> On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut 
>> wrote:
>>> Am 13.10.2013 15:52, schrieb develop32:
>>>> On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut 
>>>> wrote:
>>>>> Am 13.10.2013 14:08, schrieb develop32:
>>>>>> Windows task manager shows constantly increasing memory 
>>>>>> usage of my D
>>>>>> application, yet there is ZERO allocation done by it at 
>>>>>> the time. I
>>>>>> have
>>>>>> made a hook inside the rt/lifetime.d for _d_allocmemory, 
>>>>>> and I do get
>>>>>> notified when an array or a class object in constructed.
>>>>>> What could be the source of rapidly climbing (hundred 
>>>>>> kilobytes per
>>>>>> second) memory usage?
>>>>>
>>>>> If your programm is a 32-bit application the GC most likely 
>>>>> leaks
>>>>> memory because it thinks its still referenced. Try 
>>>>> compilling your
>>>>> application for 64-bit. If the problem goes away it's not 
>>>>> your fault.
>>>>> A possible workaround for this situation is to allocate 
>>>>> large blocks
>>>>> of memory which you know will not contain any pointers with 
>>>>> GC.malloc
>>>>> manually and specifying the "don't scan" flag.
>>>>>
>>>>> If the problem still exists in a 64-bit application you 
>>>>> most likely
>>>>> continue to allocate memory that remains referenced. Make 
>>>>> sure you
>>>>> don't have any infinitly growing arrays or other containers 
>>>>> that still
>>>>> reference the memory you allocated.
>>>>
>>>> I've added GC.collect and GC.minimize() at the end of each 
>>>> frame, looks
>>>> like the growth has stopped, so its not a 32-bit problem yet.
>>>
>>> Well the GC doesn't kick in always. It only collects memory 
>>> when its
>>> neccessary (a certain limit is reached). For a game it is 
>>> usually a
>>> good idea to run the GC every frame to avoid the ocasional 
>>> long pause
>>> times that otherwise occur. Or you could work around the GC 
>>> entierly.
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> Indeed, I tried to work around it and use manual memory 
>> management a
>> year ago, but everything felt so ugly that I decided to throw 
>> that and
>> go the idiomatic way.
>> I'm bit surprised that even with GC running every frame I 
>> haven't
>> noticed a drop in performance, even when using more than 1 gb 
>> RAM.
>
> Did you profile how much time the GC takes every frame?
> For me that was 8-9 ms every frame. That was not acceptable for 
> my case.

Currently it is 3 ms, would love to drop that to one.
Though I'm using a very slow laptop, can't play any AAA game 
released in last 5 years.


More information about the Digitalmars-d-learn mailing list