What are (were) the most difficult parts of D?

Dom Disc dominikus at scherkl.de
Tue May 17 22:42:12 UTC 2022


On Tuesday, 17 May 2022 at 06:28:10 UTC, cc wrote:
> having had this leave a pretty bad taste in my mouth, I now 
> avoid the GC whenever possible, even when I don't have to.

Bad idea. You should only avoid GC if your profiling shows that 
it is bad in a specific piece of code (e.g. some inner loop 
that's called millions of times - the real bottlenecks). This 
frees you from the mental load of thinking about memory 
allocation at all unless it becomes necessary, which it will 
actually be only in very, very few places.
Better invest your precious time to really DO profiling and find 
out where the bottlenecks are!

> Maybe a run-and-done program can get along just fine allocating 
> everything to the GC.  But maybe I'll need to modularize it 
> some day in the future and call it from another program with 
> far more intensive requirements that doesn't want superfluous 
> data being added to the GC every frame.

Yes - and when you modularize your program, keep in mind that a 
module should avoid allocating anything large or often on its own 
at all. It should better work on memory given to it. So you 
remain able to decide on the calling side if you allocate by GC 
(default) or (if something turns out to be a bottleneck) manually 
allocate memory.

> Far better to just keep your house clean every day than let the 
> trash pile up and wait for the maid to come, IMO.  Inevitably 
> it's going to be her day off when you have guests coming over.

There's always gc.collect, which calls the maid to do her job, 
even if she is on vacation. Do so whenever you think you may have 
piled on a lot of trash and are out of house (have the time 
available that a collection may take). This way you can be sure 
there is never too much trash, so the GC is very unlikely to ever 
disturb you when there is no time for long collection cycles.



More information about the Digitalmars-d-learn mailing list