digitalmars.D.learn - GC: Memory keeps growing
- Chris (10/10) Apr 15 2015 My garbage collected app starts with ~10 MB in memory, however
- Rikki Cattermole (3/12) Apr 15 2015 Sounds like you are doing a LOT of allocations. Try with -vgc during
- Chris (11/32) Apr 15 2015 Just did that, for the most part it's:
- Rikki Cattermole (3/27) Apr 15 2015 The only real suggestions here are -vgc and @nogc.
- Kagamin (2/4) Apr 16 2015 See if switching to 64-bit mode changes anything.
- Chris (11/15) Apr 17 2015 64bit is the default. I've monitored the program for a while and
My garbage collected app starts with ~10 MB in memory, however with every execution of code it grows by at least 0.2 MB (or more depending on the input). Although I can see memory being freed (say it goes up to 32 MB and drops to 14 MB), it keeps on growing slowly but surely. I use structs for the most part [1] and reuse arrays at critical points, clearing them with destroy() after use. Maybe this is the problem? I dunno. I'd be grateful for any hints. [1] The few classes I use are either singletons or instantiated only once and cached when the programs starts.
Apr 15 2015
On 15/04/2015 11:44 p.m., Chris wrote:My garbage collected app starts with ~10 MB in memory, however with every execution of code it grows by at least 0.2 MB (or more depending on the input). Although I can see memory being freed (say it goes up to 32 MB and drops to 14 MB), it keeps on growing slowly but surely. I use structs for the most part [1] and reuse arrays at critical points, clearing them with destroy() after use. Maybe this is the problem? I dunno. I'd be grateful for any hints. [1] The few classes I use are either singletons or instantiated only once and cached when the programs starts.Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Apr 15 2015
On Wednesday, 15 April 2015 at 11:48:26 UTC, Rikki Cattermole wrote:On 15/04/2015 11:44 p.m., Chris wrote:Just did that, for the most part it's: - indexing an associative array may cause GC allocation - operator ~= may cause GC allocation - operator ~ may cause GC allocation Whereas "'new' causes GC allocation" is rare and applies only to classes that are instantiated only once. I use appender a lot, too. There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.My garbage collected app starts with ~10 MB in memory, however with every execution of code it grows by at least 0.2 MB (or more depending on the input). Although I can see memory being freed (say it goes up to 32 MB and drops to 14 MB), it keeps on growing slowly but surely. I use structs for the most part [1] and reuse arrays at critical points, clearing them with destroy() after use. Maybe this is the problem? I dunno. I'd be grateful for any hints. [1] The few classes I use are either singletons or instantiated only once and cached when the programs starts.Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Apr 15 2015
On 16/04/2015 12:03 a.m., Chris wrote:On Wednesday, 15 April 2015 at 11:48:26 UTC, Rikki Cattermole wrote:The only real suggestions here are -vgc and nogc. Something must, must be holding on to references.On 15/04/2015 11:44 p.m., Chris wrote:Just did that, for the most part it's: - indexing an associative array may cause GC allocation - operator ~= may cause GC allocation - operator ~ may cause GC allocation Whereas "'new' causes GC allocation" is rare and applies only to classes that are instantiated only once. I use appender a lot, too. There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.My garbage collected app starts with ~10 MB in memory, however with every execution of code it grows by at least 0.2 MB (or more depending on the input). Although I can see memory being freed (say it goes up to 32 MB and drops to 14 MB), it keeps on growing slowly but surely. I use structs for the most part [1] and reuse arrays at critical points, clearing them with destroy() after use. Maybe this is the problem? I dunno. I'd be grateful for any hints. [1] The few classes I use are either singletons or instantiated only once and cached when the programs starts.Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Apr 15 2015
On Wednesday, 15 April 2015 at 12:03:49 UTC, Chris wrote:There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.See if switching to 64-bit mode changes anything.
Apr 16 2015
On Thursday, 16 April 2015 at 18:51:25 UTC, Kagamin wrote:On Wednesday, 15 April 2015 at 12:03:49 UTC, Chris wrote:64bit is the default. I've monitored the program for a while and it seems that it is not growing indefinitely. It might go up from 10 MB to 20 MB, but then it is happy with 20 MB for ages. It might even go down to 14 MB again, only to increase to 16 or 18 MB later. It's a bit weird. I analyzed it step by step but I couldn't find a culprit. Sometimes it stays constant for ages like 15.2 MB no matter what I put through it. Then I put one word through it and it goes up to 15.4 MB. It's a bit odd. However, I don't know the exact behavior of the GC, but it's a good time to start looking into it.There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.See if switching to 64-bit mode changes anything.
Apr 17 2015