High memory usage in vibe.d application

Anton Fediushin fediushin.anton at yandex.com
Fri Jun 29 17:40:07 UTC 2018


On Friday, 29 June 2018 at 16:49:41 UTC, Bauss wrote:
> On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
>> On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole 
>> wrote:
>>> On 29/06/2018 11:09 PM, Anton Fediushin wrote:
>>>> It is GC's fault for sure, I built my program with 
>>>> profile-gc and it allocated a lot there. Question is, why 
>>>> doesn't it free this memory?
>>>
>>> Probably doesn't know that it should deallocate so eagerly.
>>> A GC.collect(); call may help.
>>
>> That's a good idea. GC really needs to be kicked in once in a 
>> while because it did _nothing_ in 8 hours, even though my 
>> application is just a couple of timers - it isn't a hard task 
>> for CPU or memory and there's plenty of time to collect some 
>> garbage.
>>
>> Now I finally understand why GC is not a great thing. I was 
>> writing apps utilizing GC for a long time and never had 
>> problems with it, but when it came down to this simple program 
>> it stabbed me in the back.
>
> I wouldn't really blame the GC. There is a higher chance you're 
> just not using it how it's meant to be, especially since it 
> looks like you're mixing manual memory management with GC 
> memory.

I am not quite sure what should I blame now, because even if I 
use malloc for memory allocation, memory goes... somewhere?

So, long story short:
- Usage of Mallocator instead of theAllocator made it a little 
bit better
- VibeManualMemoryManagement had no (or little) effect
- Manually calling GC.collect had no (or little) effect

It makes me think that error is somewhere else. I made a code 
snippet of my testing program: https://gitlab.com/snippets/1729304

There are some changes to it:
- It uses different stream with metaint of 32KB
- It calls nowPlaying() every second

Now I will take a break from this, dealing with this kind of 
nonsense annoys me.



More information about the Digitalmars-d-learn mailing list