Have you written enough D code where you have seen the current
GC is not good enough for you? How much good has to be the D GC
for you to use it?
Bye,
bearophile
Hi,
As I said at the start, I have been away a while but I wrote a
fair amount of code in D about a year ago to test the waters.
From my experience of those tests, I mainly targeted the GC and
if I remember well, I had written code that, based on command
line switches, specified if the incorporated GC is to be used for
memory allocation/deallocation or whether memory is done entirely
manually (I managed this through some posts in the forum where
community members instructed me how to achieve this).
From my limited tests, the ones which used manual memory
management ran in roughly half the time; the GC ones took almost
double the time and in some cases more than that. I don't have
the code at hand (I might need to dig it out), but I certainly
can vouch for a significant discrepancy in performance between
the GC versions and manual versions. So yes, this is a
significant issue (i.e. the current GC is not good enough for me
and I cannot overlook it).
As for your second question (i.e. how good the GC needs to be for
me), I would probably be satisfied with a GC that matches the
Java one (used in conjunction with D's ability to take over
memory management completely in the critical parts where needed)
- but admittedly, I don't know the implications in achieving that
within D's memory model, etc.
I am embarking on a start-up pretty soon and I have been looking
at possible languages/frameworks to use; I've looked at Go in
detail, had a cursory look (so far) at Rust and have also used to
a fair degree. D is the most natural fit for me and my team
coming from a mainly C++ and Java background, but I would really
like to make an informed decision vis-a-vis the GC implications.
Thanks for your help.
- Adrian.
