[m-users.] A question about in-place updating...

[Julien Fischer]

Hi,

On Mon, 28 Aug 2023, Sean Charles (emacstheviking) wrote:

> OK, I am now creating flight-path / animation / tweening system, that
> on every iteration of the game loop, will have to process every single
> instance of display objects and update their coordinates and set
> flags, alpha values etc etc. The number of such objects could become
> high, not punishingly high, for now I can't see it being more than a
> thousand, even with a primitive particle system generating explosions
> using texture maps it should not be massively high.
>
> Currently I am just 'making it work', gut I am wondering longer term
> about what techniques might be open to me in Mercury given that it
> manages memory, does the garbage collection for me etc. such that I
> can minimise object allocation etc as instances are updated
> frame-by-frame.
>
> 1) When I use list.reverse(), is it a shallow or deep copy of the
> original? I am assuming a shallow copy, with may be copy-on-write
> behind the scenes?

Shallow. The skeleton of the list will necessarily be allocated afresh
(since Mercury lists are singlely-linked), but the elements will be
shared between the original list and its reverse.

> 2) If I have a list of say a thousand instances of a tween object,
> then as I process them, they will need to be updated as I save the
> current value in the instance along with a done flag, so either the
> values changes or the done flag changes, either way it means that a
> new instance will be created. Is there a way to make it so that
> Mercury can in-place update these instances rather than allocating new
> ones, so that it reduces memory thrashing and heap activity etc?

You could look into use mutvars or references from the standard
library's store module, although performance-wise these may not
be all that great.
(Take a look at the various versions of the n-body benchmark in
benchmarks/progs/nbody.)

Julien.