On Sun, 23 Apr 2017 12:07:47 GMT, Sönke Ludwig wrote:

Unfortunately the GC is quite a pain point. dmd -vgc/dub -b profile-gc helps somewhat to find possible sources, but since it only accumulates allocations and ignores freed/collected memory, the numbers are not really suited to find memory leaks.

Yeah I've been keeping an eye out as you guys have been gradually shifting things to not use GC and wondering if I should do the same on some of my hotter code/allocation paths... if there was a good way of getting targeted information about which paths were hurting the most I would probably do that, but as you note it seems hard to understand "why is the GC leaving 50GB of address space sitting around", etc. It's not a giant issue for desktop use cases of course, but obviously with Vibe.d you're often trying to fit things into memory-starved VMs :)

Unfortunately it is not ready for general consumption and I had to put it on the back burner due to a general time shortage.

Ah, too bad, but I'll keep an eye out. In terms of basic high level information/sanity checks like how many fibers are currently alive/running/sleeping/whatever is there any easy way to get that information at runtime for logging purposes?

Thanks for the info!