Enhanced array appending

Steven Schveighoffer schveiguy at yahoo.com
Thu Dec 24 07:04:22 PST 2009


grauzone Wrote:

> Steven Schveighoffer wrote:
> > The problem is that adding a capacity field only works if the object is a reference type.  A value type will make either choose to make copies of the capacity field, resulting in the same stomping problem (and maybe worse), or will zero out one of the copy's capacity field, resulting in an artificial limitation for appending.  The only true way to make this work right is to have a capacity field shared among all the aliases to the same data, and the most logical place for that is in the allocated block.
> 
> I see... Go makes slices value types (which references the array data), 
> but I'm not sure how or if they handle this situation.
> 
> Then, why use a cache to find the pointer to the capacity field inside 
> the array memory block? You could just store a pointer to the capacity 
> field in the slice.
> 
> Something like this, I guess:
> 
> struct slice {
>      void* ptr;
>      size_t length;
>      array_info* array;
> }
>
> [snip]
> 
> Would this work?

Yes, but the problem I see with it is you are passing around that array_info pointer with the slice for *all* slices, not just ones you intend to use appending on.  There is plenty of code that uses arrays and slices without ever doing appending, so that extra pointer is wasted space, and also increases the cost of passing slices by value.

Your idea is essentially the idea behind my patch, except you can get the array info without having an additional pointer.  The cost of lookup for the block info is mitigated by the cache, making lookups cost very little.

The patch is a compromise between performance for appending and performance for everything else.  I think there will still be a need in specialized code for a fatter array type that allows appending without complicated GC lookups, but the patch provides safe appending for a reasonable performance hit without affecting other aspects of array usage.  As with all compromises, there are always different ways of doing things, so time will tell if this patch is the best method.

-Steve



More information about the Digitalmars-d mailing list