On Tuesday, 30 September 2014 at 22:32:26 UTC, Sean Kelly wrote:
Would delete on the D side work here? Or the more current destroy()? ie. is release of the memory a crucial part of the equation, or merely finalization?
Destruction of an object is *far* more important than releasing memory. Our D code's memory usage is drops in an ocean, but it can potentially hold on to resources that need to be destroyed in special ways depending on middleware/threading usage. Object.destroy() would do the job, but there's also a fragmentation problem that creeps in to a GC solution like the default D implementation the longer you have your application running. We already encounter plenty of cache-incoherent code in other areas of the codebase, and since one of my roles is to evangelise D (so to speak) I'm aiming to keep it running fast and avoiding as many stalls as possible. If I avoid the current implementation's garbage collection, then memory allocated stays in roughly the same region (some work that I did manage to do and intend on submitting a pull request for allows a user to specify a custom set of allocation functions, so all memory from core and phobos goes through our supplied memory allocator). Either way, it still comes down to a function call to free your object which means you're stepping outside of the way the GC natively does things.