Arrays and tuple write (setelement) optimization

Hakan Stenholm <>
Fri Jul 6 17:33:00 CEST 2001


I've spent a bit of time recently testing the read/write performance of 
different erlang data types:

Test Machine: Apple G4 tower Mac (400 Mhz, MacOsX)

ETS           : about 500,000 reads or writes per second (at any ets table size)
Tuples (read) : about 4,500,000 reads (at any tuple size)
Tuples (write): slower than ets when tuple size > 100
                number of writes = c/TupleSize (where c is some constant)

Tested sizes = 1 - 100,000
Note: old (R5 ?) OTP had performance problems with large lists because they 
where converted to lists.


Some problems like matrix multiplication or rescaling bitmap pictures are very 
simple to do if one got an array like data type (read and write O(1)) ets has 
array like behaviour but a rather large overhead compared to things like a 
tuple. Acording to my tests tuples and lists are about the fastest data types in 
Erlang so I started to think if it was possible to increase tuple write speed:

* A destructive update rather than creating a copy of the pointer array that
  keeps track of the elements of the tuple should be similar in perfromance to 
  a tuple read operation

* Destructive updates are problematic if several processes keep the same tuple,
  this is not the case each one keeps its own copy - so there is only one GC
  memory heap to consider.  

* Execution in a single process is sequential i.e. functions are run in the   
  order they are written, this means that it should be risk free to 
  destructivly update a tuple if the old version of it will not be used later
  in the same clause. It can easily be determined at runtime if a destructive 
  update can be used or if it must be a copy update. 
  
* It seams reasonable to assume that we could get about 4,500,000 tuple write
  operations as well useing such a optimization. 

So I'm wondering if someone has considered adding such a optimization to the 
erlang compiler/VM or are there any problems I forgot about ?

  




More information about the erlang-questions mailing list