[mercury-users] Structure reuse

Simon Taylor stayl at cs.mu.OZ.AU
Tue Jul 15 10:01:30 AEST 2003

On 15-Jul-2003, Michael Day <mikeday at yeslogic.com> wrote:
> > Generally structure reuse optimization will only improve the speed of
> > the program, not its space usage.  The reason is that the memory which
> > structure reuse reuses is garbage anyway; if structure reuse optimization
> > is not done, the memory will be reclaimed automatically by the garbage
> > collector.  The advantage of structure reuse is that it increases speed
> > by improving locality and by making garbage collections less frequent.
> I realise that the memory will eventually be reclaimed by the garbage
> collector, but I'm hazy as to exactly *when* it will be reclaimed.
> For example, given this predicate for updating a tree:
> update(T0, T) :-
>     update0(T0, T1),
>     update1(T1, T2),
>     ...
>     updateN(TN, T).
> It would be nice to be able to write code like this and have the compiler
> determine that it can update the tree in-place, eliminating unnecessary
> copying and memory allocation, improving locality, reducing memory usage
> and so on. I have no idea whether that is feasible though, or whether it 
> would require assistance from the programmer by specifying unique modes or 
> something like that.

In practice, if you want to be sure that the optimization takes place
you'll need to specify unique modes (sorry, not working yet) rather
than relying on automagic compiler analyses.  Relying on the compiler
to do the work will result in difficult to track down performance bugs
where a data structure which should be single threaded actually isn't.

mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe

More information about the users mailing list