Have you try use VibeManualMemoryManagement https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22
On Fri, Jun 29, 2018 at 3:20 PM Anton Fediushin via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > 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. > > >
