Frameworks and libraries

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Sep 15 01:06:13 UTC 2023


On Thursday, September 14, 2023 10:30:27 AM MDT user548215 via Digitalmars-d 
wrote:
> On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe
>
> wrote:
> > This is a mistaken decision.
>
> Can you explain why?

In general, using the GC allows for code that's both safer and cleaner (in
fact, @safe is pretty much impossible for a lot of code without it). It's
also generally easier to write and maintain code that uses a GC rather than
manual memory management. And performance-wise, whether it's better or worse
very much depends on what you're doing.

In general, the GC costs very little until it needs to run a collection, at
which point, the program temporarily stops to try to collect garbage.
Depending on what your program is doing in that section of code, this either
really doesn't matter, or it could be a big problem. If it does matter, then
there are ways to mitigate the problem (e.g. disabling the collector in key
parts of the program or reusing memory so that less garbage is produced, and
there's less memory to scan). In the extreme case, you might need a thread
that doesn't use the GC at all so that you can guarantee that it never stops
(e.g. for real-time applications), but for the vast majority of programs,
you can just use the GC without worrying about it all, and then if profiling
shows that it's become a problem in a particular section of your program,
you deal with that section in whatever manner is most appropriate so that
the GC isn't a problem there. The end result is generally a much more
maintainable program than if you were using manual memory management
everywhere.

Another alternative to a GC is reference counting, which then avoids the
stop-the-world problem that comes with the GC, but the result is that the
cost of handling a collection is amortized across the program as a whole
instead of happening only at key points. So, the program avoids pauses but
is likely to be slower in the rest of the program as a result. You also then
have to worry about pointer/reference cycles in away that GC-managed code
does not (it's why some languages - e.g. python - have a hybrid approach
where they use reference counting for most stuff and then let their GC take
care of the cycles). So, whether reference counting or the GC is better very
much depends on your code, but it's certainly true that some folks prefer
reference counting simply because of a fear that GCs are slow (and they can
be slow depending on what the language or libraries are doing, but they're
not necessarily slow). A lot of the fear about GCs being slow comes from
what the situation was 30+ years ago with languages that used a GC (many of
those being functional languages, which is a very different situation from
what a language like D has).

So, whether the GC is even a problem is very program-dependent, but it
allows us to have language features that we couldn't have otherwise (e.g.
the way that dynamic arrays work in D isn't really possible without a GC;
you have to do a lot more explicit memory management with them if you avoid
using the GC, and that can get far more complex). And using the GC prevents
whole classes of bugs that come with manual memory management. So, avoiding
the GC just because you're afraid that it's going to make your program slow
is going to hamper what you can do in D for arguably minimal benefit. D does
allow you to avoid the GC when you really need to, but using the GC allows
you to write cleaner, more maintainable, less buggy programs than you get
with manual memory management.

Also, while D does allow you to write code without the GC, because it's
generally assumed that you're going to be using it (to the point that some
language features require it), trying to avoid it in your code in general is
likely to just make life harder for you, and if you really want to go that
route, it would arguably be better to just write in C++ where everything is
designed with the idea that you're unlikely to be using a GC. It's one thing
to avoid the GC in specific sections of your code in D, whereas it's quite a
bit more painful to avoid it everywhere.

- Jonathan M Davis





More information about the Digitalmars-d mailing list