Re: Replacing XML::Simple XMLout with Lib::XML

Have we made a fundamental error somewhere...

I think yes. Your libxml_output() re-structures the passed $xml, then stringifies, the xmlsimple_output() just stringifies the passed $xml, generated by XMLin() beforehand. The subroutines are not comparable.

Just measuring the performance of stringification ...

#!/usr/bin/perl -w
use strict;
use XML::Simple;
use XML::LibXML;
use Benchmark qw(cmpthese);

my $file = shift or die "usage: $0 xmlfile\n";

my $xml = XMLin( $file);
my $dom = XML::LibXML->load_xml(location => $file);

cmpthese ( -1, {
        simple => sub { XMLout($xml) },
        libxml => sub { $dom->toString() },
    }
);
__END__
         Rate simple libxml
simple 29.4/s     --   -96%
libxml  658/s  2141%     --
[download]

... gives a different picture. Are you working internally with $xml or $dom ?

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Comment on Re: Replacing XML::Simple XMLout with Lib::XML Select or Download Code

Replies are listed 'Best First'.
Re^2: Replacing XML::Simple XMLout with Lib::XML by amasidlover (Sexton) on Feb 15, 2018 at 14:56 UTC
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' } } };` [download] 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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Replacing XML::Simple XMLout with Lib::XML
by amasidlover (Sexton) on Feb 15, 2018 at 14:56 UTC

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'
                                                     }
                                     }
        };
[download]

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.

[reply]
[d/l]