> So regarding the GC, does it mean, that even with --d:malloc the allocator > will hold that memory until whole process quits?
That depends on a lot of factors. Generally allocators will hold on to a certain amount of memory for performance reasons. Here's an interesting read on the topic: <https://www.algolia.com/blog/engineering/when-allocators-are-hoarding-your-precious-memory/> > Along with that mistake in code, I forgot also mention that I specified this > parameter in nim.cfg If so, I really don't understand what to do with it? > Switch to manual memory management? What options we can have when program > needs to use actively ram, and alloc/dealloc objects with immediate real > free()? It'd help to clean up your code a bit first and make it more idiomatic. Even in a GC'ed language it's possible to leak. The usage of raw pointers makes me think that's a possible culprit in your case. Try to avoid `ptr` and use `ref` instead. Using `ptr` is natural in C, but is rarely needed in Nim. You can simplify your code using by switching from `ptr OrderedTable` to `OrderedTableRef`. It'd also remove the need for manual `[]` derefs. Additionally you can run you Nim program compiled with `--useMalloc` using valgrind to check for memory leaks / threading issues. Lastly, Nim defaults to copying strings on assignment so you shouldn't need to use `copy=` manually. Once you get that figured out, I'd suggest playing with turning `--useMalloc` on and off, and maybe finding some environment variables for GLIBC (or the MacOS / Windows equivalents). Note that figuring out the actual spaced used can be tricky, RSS vs VSS, etc. Also, @araq's new [malebolgia](https://github.com/Araq/malebolgia/tree/master) might be easier to use for your multi-threading. It's experimental but seems nice for these sorta tasks. > I'm not very experienced in different Gc's and their working principles, but > I thought GC will use the ram optimally. But with current example, such > executable can hold a lot of ram on the server, while other heavy executable > may need it. For example until the exe will not save processed data on the > disk, all that GigBytes will be hold. Yes and no, GC's can be very complicated but in my experience and can be tuned for different properties. For example, Java's GC tends to be tuned for throughput at the expense of using more RAM. Go's GC tends to be tuned for lower memory usage. Generally though reference counting like Nim's ARC/ORC will use less RAM as it'll generally be freed sooner. Note that some folks don't even consider pure reference counting a GC!
