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

Julien Fischer <[email protected]>
Newsgroups gmane.comp.lang.mercury.general
Message-ID <[email protected]>
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.
_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.