Hi Marc,

> At the moment, the header file exposes an opaque struct Hamt and
> communication with the code happens through (stack-allocated) pointers
> to a Hamt. In the implementation, however, each Hamt just consists of
> two pointers (a pointer to a function table and a pointer to the
> root), so stack-allocating Hamts instead and passing them around by
> values makes as much sense.
> 
> This would have the advantage of reducing heap allocation.

By how much does it reduce the heap allocation? Say, someone allocates
a HAMT and adds 100 entries. There will be heap allocations of ca. 5-10
buckets and internal nodes. Adding one more heap allocation for the
root object is not a tragedy.

So, in the end the question is whether to optimize the case of small HAMTs.

> The disadvantage would be that adding further fields to a Hamt in future
> extensions might be more problematic

True. But when this happens we can mitigate this through a warning in the
NEWS file.

> and that identity of Hamts cannot
> be decided through pointer identity anymore (so the protocol how to
> decide whether an element has been inserted or not has to be changed).

Does this protocol change introduce a significant slowdown?

Bruno


Reply via email to