To GC or Not To GC

To directly answer your two questions:

1. Yes, creating class instances by reference does result in a lot of heap activity, but:

   a. In D, you have struct as well as class. A struct has value semantics and can do everything a class can, except polymorphism.

   b. Polymorphism and value semantics have never worked well together due to the slicing problem.

   c. In D, if you really need to allocate a class instance on the stack in some performance-critical code and don’t care about the loss of safety, you can do so without unreasonable hassle via the scoped function.

2. GC can be comparable to or faster than manual memory management if:

   a. You still allocate on the stack where possible (as you typically do in D) instead of relying on the heap for everything (as you often do in other GC’d languages).

   b. You have a top-of-the-line garbage collector (D’s current GC implementation is admittedly somewhat naive, though it has seen some major optimizations in the past few releases, so it’s not as bad as it was).

   c. You’re allocating mostly small objects. If you allocate mostly large arrays and performance ends up being a problem, you may want to switch a few of these to the C heap (you have access to C’s malloc and free in D) or, if it has a scoped lifetime, some other allocator like RegionAllocator. (RegionAllocator is currently being discussed and refined for eventual inclusion in D’s standard library).

   d. You don’t care that much about space efficiency. If you make the GC run too frequently to keep the memory footprint ultra-low, performance will suffer.