Ah, sorry I didn't make it clear - in the production code there is no file to load from - here its just a handy way of getting a similar hashref to do timings on. So we can't just compare stringification; we have to convert hashref to $dom then stringify.
Internally in the 'real' system we have 30 odd Classes some of which with 5-10 polymorphic variants that all have a method called output which returns a nested hashref/arrayref structure that can be converted into JSON/XML/Storable etc. These are all assembled into one giant hashref before conversion.
For the example I simply used XMLin to create a hashref that would be similar to what we already - internally (in our real framework) we're working with something that resembles $xml (which is badly named and perhaps should be $nested_hashref_containing_arrayrefs_and_hashrefs). A tiny fragment of it would look like:
$VAR1 = {
'RelationshipPermissions' => {
'PermissionHolderType' => {
'cont
+ent' => 'authenticated'
},
'ZName' => {
'content' => 'svz_
+admin_rp'
},
'DisplayName' => {
'content' =>
+ 'Admin Permissions'
},
'IPList' => {
'content' => 'any'
},
'changeable' => {
'content' => 't
+rue'
},
'readable' => {
'content' => 'tru
+e'
},
'deleteable' => {
'content' => 't
+rue'
},
'appendable' => {
'content' => 't
+rue'
},
'secureable' => {
'content' => 't
+rue'
}
}
};
So whilst the stringification is quicker if we already have a complete DOM object structure - we don't already have that and modifying our code to produce that would a) be a massive task and b) make it more difficult (impossible / slower) to also produce JSON / Storable output.
|