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