<div dir="ltr">Have you try use VibeManualMemoryManagement<div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(36,41,46);width:1px;height:1px"><a href="https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22">https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22</a></pre></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 29, 2018 at 3:20 PM Anton Fediushin via Digitalmars-d-learn <<a href="mailto:digitalmars-d-learn@puremagic.com">digitalmars-d-learn@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Friday, 29 June 2018 at 11:42:18 UTC, bauss wrote:<br>
> On Friday, 29 June 2018 at 11:24:14 UTC, Anton Fediushin wrote:<br>
>> On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:<br>
>>> On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:<br>
>>>> On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin <br>
>>>> wrote:<br>
>>>>> Almost forgot, there are two timers which call this <br>
>>>>> function for two different streams.<br>
>>>>><br>
>>>>> Value of `metaint` is 16000, which means that only 16KB of <br>
>>>>> memory are allocated for the `buffer`, then it reads <br>
>>>>> another byte which contains length of the metadata / 16 and <br>
>>>>> then it reads the metadata which is 100-200 bytes long.<br>
>>>>><br>
>>>>> This gives us... 16KiB per one nowPlaying() call. Why <br>
>>>>> doesn't it free the memory?<br>
>>>><br>
>>>> Maybe use the <br>
>>>> <a href="https://dlang.org/phobos/std_experimental_allocator_mallocator.html" rel="noreferrer" target="_blank">https://dlang.org/phobos/std_experimental_allocator_mallocator.html</a> instead of theAllocator as it defaults to GC.<br>
>>><br>
>>> Thanks, I'll try that.<br>
>>> ...<br>
>>> I will deploy that and see if it changes anything.<br>
>><br>
>> It did! Memory usage went down to 7MiB yet it still grows <br>
>> slightly. I'll monitor if it changes in a couple of hours but <br>
>> it is much better.<br>
>><br>
>> Thank you a lot, Radu. It turns out that theAllocator is so <br>
>> tricky.<br>
><br>
> Again you could do @nogc and see what memory is possibly <br>
> allocated by the GC and perhaps that way you can see what <br>
> memory the GC is holding on to.<br>
<br>
@nogc tells nothing new, just an error on every single line <br>
because neither `res.bodyReader.read` nor Mallocator's functions <br>
are marked as @nogc.<br>
<br>
Compiling with dmd's `-vgc` flag shows nothing but the last line.<br>
<br>
><br>
> non-GC memory should be freed right away and those there <br>
> shouldn't be a leak from that.<br>
<br>
Using Mallocator instead of theAllocator improved the situation, <br>
but it still leaks for some reason. After 2 hours it went from <br>
7MiB to 18MiB.<br>
<br>
I will compile it with profile-gc again and look for the possible <br>
cause of that, maybe I'll try valgrind too.<br>
<br>
<br>
</blockquote></div>