Clone - clone Vs Storable - dclone

[UnderMine]

Hi Monks,

I would like some advice as to whether anyone has experience of Clone's clone Vs Storable's dclone.

A module that I have recently been using Hash::Merge uses clone in order to do a level at a time comparison of the keys used in hashs. But this has shown up a few Bugs in the underlying module Clone (including causing a Seg-fault).

I have posted a fix for Hash::Merge that by-passes the Seg fault issue in clone but does not address the Uni-code support issue.

My question is should Hash::Merge be using clone or dclone. dclone does deep cloning but is part of core perl but is slower than clone in the context of Hash::Merge which only requires single depth transversal cloning.

All thoughts welcome
UnderMine

[pg]

For now, seems that you have to settle on Storable, as there are quite a few serious bugs in Clone.

However for long term, it seems Clone would replace Storable, so expect to migrate to Clone:
1. Although Storable is also optmized, but its dclone is slower when compare to Clone's clone. This is easy to understand, as dclone is not the focus of Storable.
2. The dclone function in Storable is kind of quick-and-dirty solution, it simply serialize the data structure first, and then deserialize it to create the clone. Although it is optimized to share data between step one and two, it still does lots of things that are needed for serialization but not pure cloning.
   
   The functionality of deep clone should stay in a seperate class.

[UnderMine]

I think that at the heart here we have a core vs non-core issue.

Core modules should be upto date with the latest things that have happened

Core modules that cause seg faults tend to get fixed fast where as when a module such as Clone causes one it is not considered such an issue.

perl -e 'use Clone qw(clone); $a = \$b; undef $a; $c = clone $a;'

and

perl -e 'use Clone qw(clone); $a ={}; undef $a; $c = clone $a;'

Cause Seg faults

but

perl -e 'use Clone qw(clone); undef $a; $c = clone $a;'

and

perl -e 'use Clone qw(clone); $a =""; undef $a; $c = clone $a;'

does not cause this issue.

Core supports Uni-code but it takes time for modules to catch up. It appears that Clone does not support Unicode structures correctly :-

perl -MClone=clone  -le '%a=(chr 256 =>1);$c=clone \%a; print ord fore
+ach keys %$c'
196

as oposed to

perl -MStorable=dclone  -le '%a=(chr 256 =>1);$c=dclone \%a; print ord
+ foreach keys %$c'
256

Hope this clears up a few things
UnderMine

[pg]

I believe either Clone will become a core module, or something else fullfil the clone functionality will. From an architecture point of view, it does not make sense to mix serialization and deep clone in one class.

[Anonymous Monk]

(1.) is not entirely true. I did test 3-level hash with approximately 20 keys per level. I did try to clone the whole thing, only two level slice and finally 1 level leaf. here are results: 1level "leaf" hash: Clone is twice as fast as dclone 2level hash: dclone is a slightly faster (assume the same) whole 3level hash: both are nearly the same (very slight ~1% advantage to Clone) everyone can setup own test but I think Clone has slight advantage only for very small structures. I would go with dclone. my 2c :) good luck!

[abatkin]

I am not sure exactly what you need to do, but I wonder if you even need an external cloning function. If all you really need is to clone one level deep, perhaps you could just implement exactly what you need in plain perl?

dclone is wonderful if you really want to clone a complex data structure. Last I checked it can deal with nearly anything, including cycles, which normally would be more challenging to deal with on your own. That is the beauty of Storable, you need not worry how complex or cyclic your data structure is, it all Just Works. It just seems a bit much to go through all this work if all you need is the first level cloned.