www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Faster way to .dup an AA?

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
I'm currently doing something like this:

int[char[]] source;

...

int[char[]] dest;

foreach(k, v; source)
    dest[k] = v;

But that loop is not very high-performance.

Is there any other way to dup an AA that's better performance?  Something is 
telling me "no."  It would be so nice if this were a supported property for 
AAs, so the implementation could come up with a faster way to .dup it.. 
May 01 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 I'm currently doing something like this:
 
 int[char[]] source;
 
 ...
 
 int[char[]] dest;
 
 foreach(k, v; source)
     dest[k] = v;
 
 But that loop is not very high-performance.
 
 Is there any other way to dup an AA that's better performance?  Something is 
 telling me "no."  It would be so nice if this were a supported property for 
 AAs, so the implementation could come up with a faster way to .dup it.. 
 
 

Sadly I haven't found anything either. It seems they ought to have a direct .dup property just like fixed/variable arrays. You can do (aa1 = aa2) but this turns out to be analogous to slicing; any later changes to aa1 also appear in aa2. Which infers to me that AA's are referance types perchance?? At least insofar as arrays are, as a struct with a pointer? This means there may be a "hack" to get a direct dup using memcpy, but I'm not sure how to get at that pointer safely. Bah. -- Chris Nicholson-Sauls
May 01 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Nicholson-Sauls wrote:
 Jarrett Billingsley wrote:
 I'm currently doing something like this:

 int[char[]] source;

 ...

 int[char[]] dest;

 foreach(k, v; source)
     dest[k] = v;

 But that loop is not very high-performance.

 Is there any other way to dup an AA that's better performance?  
 Something is telling me "no."  It would be so nice if this were a 
 supported property for AAs, so the implementation could come up with a 
 faster way to .dup it..

Sadly I haven't found anything either. It seems they ought to have a direct .dup property just like fixed/variable arrays. You can do (aa1 = aa2) but this turns out to be analogous to slicing; any later changes to aa1 also appear in aa2. Which infers to me that AA's are referance types perchance?? At least insofar as arrays are, as a struct with a pointer? This means there may be a "hack" to get a direct dup using memcpy, but I'm not sure how to get at that pointer safely. Bah.

I think that's pretty hopeless. AA's should have a dup property, plain and simple. The implementation of AA's isn't specified by the spec (I don't think the performance characteristics even are), so anything you manage to get working in terms of a "raw dup" is going to be implementation-dependent. --bb
May 02 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
news:f19958$1a8g$1 digitalmars.com...
 Which infers to me that AA's are referance types perchance??  At least 
 insofar as arrays are, as a struct with a pointer?  This means there may 
 be a "hack" to get a direct dup using memcpy, but I'm not sure how to get 
 at that pointer safely.  Bah.

They are. The hash tables themselves are allocated on the heap, and then each element is a binary tree of heap-allocated nodes. Making it very difficult to duplicate them, even if I use a non-portable hack. I think I'll write a double hash table which doesn't use separate chaining. That way, I'll be able to copy all the data with "newTable.data = oldTable.data.dup".
May 02 2007