Heap based mutable arrays?

[Sean Hinde]

All,

Support for mutable arrays has almost got to the point of a FAQ.

The current choices seem to be:

tuples - slow when of any decent size due to the copying involved
ets - quite a lot of fixed overhead (min 50uS on my machine).
clever combinations of smaller tuples such as dynarray and friends.. not too
bad - comparable to ets.

We hear that supporting automatically mutable tuples is not possible due to
the nature of the current garbage collector - in R8 there is an optimisation
for multiple updates in one go within a record but it still gets copied.

So..

Why not have a new bif library called e.g array with the same semantics as
ets but without the hashing and buckets overhead?

It could have much the same interface as ets e.g.

A = array:new(array_name, [{initial_offset, 1}, {max_index, 1000}]).
array:insert(A, N, Term).
array:delete(A, N).
array:update_counter(A, N, 1).
array:delete(A).

It would have the same copying overhead as ets (copying the term to the heap
- unless storing a large binary) but this is probably not the end of the
world.

I don't see there would be a need for garbage collection - just delete the
whole thing on the demise of the creating process. It would need to do some
tidying up work in the background if we insert a larger term than last time
(or some default minimum?)

Any thoughts?

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.