Arrays and tuple write (setelement) optimization
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