On Friday, 29 June 2018 at 11:42:18 UTC, bauss wrote:
> On Friday, 29 June 2018 at 11:24:14 UTC, Anton Fediushin wrote:
>> On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:
>>> On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
>>>> On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin
>>>> wrote:
>>>>> Almost forgot, there are two timers which call this
>>>>> function for two different streams.
>>>>>
>>>>> Value of `metaint` is 16000, which means that only 16KB of
>>>>> memory are allocated for the `buffer`, then it reads
>>>>> another byte which contains length of the metadata / 16 and
>>>>> then it reads the metadata which is 100-200 bytes long.
>>>>>
>>>>> This gives us... 16KiB per one nowPlaying() call. Why
>>>>> doesn't it free the memory?
>>>>
>>>> Maybe use the
>>>> https://dlang.org/phobos/std_experimental_allocator_mallocator.html instead of theAllocator as it defaults to GC.
>>>
>>> Thanks, I'll try that.
>>> ...
>>> I will deploy that and see if it changes anything.
>>
>> It did! Memory usage went down to 7MiB yet it still grows
>> slightly. I'll monitor if it changes in a couple of hours but
>> it is much better.
>>
>> Thank you a lot, Radu. It turns out that theAllocator is so
>> tricky.
>
> Again you could do @nogc and see what memory is possibly
> allocated by the GC and perhaps that way you can see what
> memory the GC is holding on to.

@nogc tells nothing new, just an error on every single line
because neither `res.bodyReader.read` nor Mallocator's functions
are marked as @nogc.

Compiling with dmd's `-vgc` flag shows nothing but the last line.

>
> non-GC memory should be freed right away and those there
> shouldn't be a leak from that.

Using Mallocator instead of theAllocator improved the situation,
but it still leaks for some reason. After 2 hours it went from
7MiB to 18MiB.

I will compile it with profile-gc again and look for the possible
cause of that, maybe I'll try valgrind too.