large tuples (was RE: OT? -NO! Essay: Programming as if Performan ce Mattered)

Ulf Wiger (AL/EAB) ulf.wiger@REDACTED
Fri May 7 13:51:32 CEST 2004



> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Peter-Henry
> Mander
> Sent: den 7 maj 2004 10:18
> To: erlang-questions@REDACTED
> Subject: Re: OT? -NO! Essay: Programming as if Performance Mattered
> 

> And a third: "Changing element 50 of a 1,000,000 element tuple results
> in a new 1,000,000 element tuple." I've written some code to seek and
> replace tagged tuples in a tree-like Erlang term by following a path
> defined as a list of tag atoms which lead to the tagged tuple to
> replace.
> 
> Is there a way I can represent a potentially large term in a way that
> avoids copying the whole term for each replacement e.g. using ets to
> represent the tree allowing in-place changes, followed by 
> recreating the
> whole modified term when modifications are finished?

The 'lines' contrib on jungerl can actually be used for this.
It's basically a tuple tree with array semantics.

(There is also a 'dynarray' contrib on erlang.org, but 
lines is at least as efficient and more sophisticated.)

The idea was to use it for e.g. editors, where you want an
array of lines, but the lines.erl module doesn't really care
how a "line" is represented -- it can be any erlang term.

You can either create a new empty array, or dimension it 
for a default number of lines/elements. After this, you can
use update/insert/append/delete to modify the array. For 
large arrays, it is _much_ more efficient than to update
a tuple.

As far as I know, the lines module has a user base of 1:
Joe Armstrong decided to use it for some "emacs clone"
(or rather perhaps a pico_emacs, right?)

/Uffe



More information about the erlang-questions mailing list