Smart pointers instead of GC?

deadalnix deadalnix at gmail.com
Wed Jan 2 04:32:00 PST 2013


On Wednesday, 2 January 2013 at 11:41:33 UTC, 
DythroposTheImposter wrote:
>  I'm interested in how the new LuaJIT GC ends up performing. 
> But overall I can't say I have much hope for GC right now.
>
>  GC/D = Generally Faster allocation. Has a cost associated with 
> every living object.
>

True, however, GC + immutability allow new idoms that are plain 
impossible in a non GC world, and that are really efficients at 
reducing copies and allocations (and used in many high perf D 
libs).

The comparison you present here fail to take this into account.

>  C++ = Generally Slower allocation, but while it is alive there 
> is no cost.
>

Counting reference have a cost. Plus, when the heap grow, the 
object that dies together tend to grow as well, which cause 
pauses.

Latency contrived programs, like video games, tends to avoid 
allocation altogether because of this. This obviously work both 
with GC and reference counting.

>  So as the heap grows, the GC language falls behind.
>

That is more subtle than that. Reconsider what I wrote above, for 
instance that GC + immutability can be used to reduce allocations 
(so live heap size). You'll also have to consider that GC can be 
concurrent, when reference counting usually cannot (or loose some 
of its benefit compared to GC).

>  This seems to be the case in every language I've looked at 
> this uses a GC.

Most GC language lack proper memory management, and sometime have 
design choice that are a nightmare for the GC (java have no value 
type for instance). You are comparing here way more than simply 
GC vs other memory management.

Considering the pro and cons of each, an hybrid approach seems 
like the most reasonable thing to do in any high performance 
program. Which is possible in D because of GC.free .


More information about the Digitalmars-d mailing list