View mode: basic / threaded / horizontal-split · Log in · Help
May 02, 2007
Faster way to .dup an AA?
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 02, 2007
Re: Faster way to .dup an AA?
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 02, 2007
Re: Faster way to .dup an AA?
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
Re: Faster way to .dup an AA?
"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".
Top | Discussion index | About this forum | D home