[erlang-questions] term_to_binary and record improvements

Ulf Wiger (TN/EAB) ulf.wiger@REDACTED
Fri Aug 29 10:03:57 CEST 2008

Richard A. O'Keefe skrev:
> Question:  in existing Erlang use, which is more important,
> speed of generating a binary encoding for a term, or how big
> it is (which relates to how quickly it can be sent across a
> network and how fast it can be decoded, amongst other things).

Having a sharing-preserving term_to_binary() would be a start,
but as long as local message passing doesn't preserve sharing
(neither does spawn()), we would need some big fat warning
labels on the deliberate use of sharing in data structures.

Come to think of it, we need those warning labels even today.

There are very few corners in Erlang where a seemingly
innocent code modification can cause havoc, but accidental
serialization of a complex data structure is one of them.

I can say from experience, as can John Hughes, that it's no
fun at all when a seemingly well-working program suddenly
blows up, rendering your computer useless for minutes while
it tries to allocate an enormous glob of memory.

In both cases, sharing was deliberately used, and in both
cases the fact that the data structure is flattened when
sent to another local process came as a surprise. In my
case, a subtle mistake (inheriting the whole record in a
fun, instead of just a single attribute) caused the blowup.
In John's case, there was truly a need to pass the data to
another process, but no way to do it without causing memory

BEAM already has the ability to do sharing-preserving copy:
the garbage collector obviously does it. But the feature is
not available to the lowly Erlang programmer.

Ulf W

More information about the erlang-questions mailing list