Unittests pass, and then an invalid memory operation happens after?

[H. S. Teoh]

On Wed, Apr 03, 2024 at 09:57:00PM +0000, Liam McGillivray via Digitalmars-d-learn wrote:
> On Friday, 29 March 2024 at 01:18:22 UTC, H. S. Teoh wrote:
> > Take a look at the docs for core.memory.GC.  There *is* a method
> > GC.free that you can use to manually deallocate GC-allocated memory
> > if you so wish.  Keep in mind, though, that manually managing memory
> > in this way invites memory-related errors. That's not something I
> > recommend unless you're adamant about doing everything the manual
> > way.
> 
> Was this function removed from the library? I don't see it in [the
> document](https://dlang.org/phobos/core_memory.html).

https://dlang.org/phobos/core_memory.html#.GC.free


> How is `GC.free` different from `destroy`?

GC.free is low-level. It does not invoke dtors.


[...]
> When you mention a "flag" to indicate whether they are "live", do you
> mean like a boolean member variable for the `Unit` object? Like `bool
> alive;`?

Yes.


> > My advice remains the same: just let the GC do its job. Don't
> > "optimize" prematurely.  Use a profiler to test your program and
> > identify its real bottlenecks before embarking on these often
> > needlessly complicated premature optimizations that may turn out to
> > be completely unnecessary.
> 
> Alright. I suppose that some of the optimization decisions I have made
> so far may have resulted in less readable code for little performance
> benefit.  Now I'm trying to worry less about optimization. Everything
> has been very fast so far.
> 
> I haven't used a profiler yet, but I may like to try it.

Never make any optimization decisions without a profiler. I learned the
hard way that more often than not, I'm wrong about where my program's
bottleneck is, and that I spend far too much time and effort
"optimizing" things that don't need to be optimized, while totally
missing optimizations where it really matters.  Life is too short to be
wasted on optimizing things that don't really matter.  When it comes to
optimizations, always profile, profile, profile!


[...]
> It's unlikely that I will have multiple maps running simultaneously,
> unless if I do the AI thing mentioned above. I've had a dilemma of
> passing around references to the tile object vs passing around the
> coordinates, as is mentioned in an earlier thread that I started. In
> what way do references slow down performance? Would passing around a
> pair of coordinates to functions be better?

It's not references themselves that slow things down; it's the
likelihood that using reference types when you don't need to can lead to
excessive GC allocations, which in turn causes longer GC pauses.  Well,
excessive dereferencing can also reduce cache coherence, but if you're
already at the level where this actually makes a difference, you don't
my advice anymore. :-D

Generally, if a piece of data is transient and not expected to last very
long (e.g., past the current frame), it probably should be a struct
rather than a class.  There are exceptions, of course, but generally
that's how I'd decide whether something should be a by-value type or a
by-reference type.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."