Hello elcritch! Thanks for reply. > : Generally allocators will hold on to a certain amount of memory for > performance reasons.
I believe wrapper around malloc does that? Since I used malloc() with my own manual memory management in C, and only free() will return back to the OS. In our case we don't see free() to be executed after thread exits (what is quiet bit strange). Of course I understand what performance reasons it can be. GC does not knows will the thread be executed again or not, and holds all allocations to not alloc again. > : Try to avoid ptr and use ref instead. Already did that previously, with same results. Changing to **OrderedTableRef** will not help. My first example with `=copy` and other weird stuff was used especially to point to the problem I complain. > : Additionally you can run you Nim program compiled with --useMalloc using > valgrind to check for memory leaks / threading issues. I thought --d:useMalloc used in my example should do the same? Meanwhile here compiler prints: **Error: invalid command line option: '\--useMalloc'** I use Google Sanitizers, while valgrind is indeed a good tool! I suggest you to try Dr.Memory (also nice one). > : Generally though reference counting like Nim's ARC/ORC will use less RAM as > it'll generally be freed sooner. Unfortunately it will not work for me either. The executable does it's work fast, while during saving processed data to the disk, it can hold a lot of gigs right before it exits, so at that point I expect to have only output and program data to be stored in ram. What not happens and no reasons to await Arc/Orc to do their job. I think some kind of "force Collector run" function should be included for such cases. I always can do manual MM, but having optimal for my task GC and dynamics was the reason why I choose not to do so.
