compiler question ?

[Robert Virding]

Kent Boortz <kent@REDACTED> writes:
>
>> cool.and what about lists or tuples?
>> 
>> f({A,B})->{g(A),B}. is B copied ?
>> 
>> g([H¦T])-> [k(H) ¦ T]. is T copied ? ( forget about tail recursiveness, can 
>> unmodified part of list be not copied ?
>
>When you write "copied" I assume you mean one cell (32 bits) needed
>for storing the object or a pointer to a larger object on the
>stack. The object itself is not copied in the examples above. It is
>rare that Erlang data is copied, the main occasions are when sending
>messages or storing data into ETS tables.

I think he meant the the whole object.  One of the beauties of having 
non-destructive semantics is that you can quite safely send around 
references to objects, which is what Erlang implementations do.  This 
means that you never copy more than 32-bit references.

>But there are still some optimizations missing in the compiler that
>cause some "copying". It will not transform constructs consuming heap
>space like
>
>  h({A,B}) ->
>      k({A,B}).
>
>to something equivalent that is not using heap space
>
>  h({A,B} = X) ->
>      k(X).

It is not at all certain that this is a good optimisation.  While it 
may use less heap space it may also carry some penalties:

1. It may mean that more objects become old before being dereferenced 
which is not so good with generational collectors, they love objects 
dying young.

2. It may use more stack space as it will keep more references.

If anyone has some references to tests on this optimisation please send 
them to me.

	Robert