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