XML::LibXML is also an alternative, if used in the SAX mode.

XML parsing is always a bit of a pig. Even so, I really question this situation. You must have some seriously complex XML.

100M files? When you said big I thought you were going to say a GIG or two. 100M? I've hit nearly 100M for my iTunes library xml file. Do you mind if I ask how much system memory do you have? Are you sure this is an XML issue? Can you describe the issues you are experiencing in a bit more detail?

Thank you for all your replies.
Unfortunately I'm not 100% positive that it is an XML issue, however based on my benchmarks I'm pretty sure it is. The server has 1.25 GB of RAM. It experiences relatively large loads throughout the day (~5 requests per second).
The main script on the server receives an XML packet from another server. The script takes the XML and parses it using XML::Records. The parsed records are used to build up a MySQL query. This query is then executed and the script is ended. The MySQL is on another server entirely (obviously with its own set of dedicated resources).
Here is a snippet of pretty much all the script is doing:

for my $subpkg (@$pkg)
{
    $sql .= "$delim($subpkg->{field1},$subpkg->{field2},$subpkg->{fiel
+d3})";
    $delim = ",";
}
$query = $db->do($sql);
[download]

I first thought it may be an issue with string concatenation when building up the query. However my testing has shown that concatenating strings in perl was just as efficient as running a join on an array.
The only thing I notice consistently is that when I send a 1MB XML packet to the script, it uses low memory (~4000K), however when I send it a 30MB XML packet, it uses almost triple the amount of memory (sometimes as high as 20000K).
I know that the server will most likely need a memory upgrade however I want to make sure the script is running as efficiently as possible. I'm currently looking into using XML:Twig.

Wait a second, could you show us a bit more of the code? It looks as if you were first extracting all data in the XML, building a huge string and then tried to shove the whole string into the database. I'm not surprised the script and the database need a lot of memory and CPU time to cope with that!

It would be much better to parse one row, insert it to the database using a prepare()d statement handle, forget its data, parse the next one ... and if you want to optimize it and don't mind that it's a tiny little bit more complex, open the database connection with AutoCommit=>0 and commit only after every 1000 rows (you may need to do some benchmarking to find the right number here).

Jenda


Support Denmark! Defend the free world!

There is no reason why XML parsing has to be a "pig" ... or to use a better defined term ... a memory hog. It only is if you first parse the whole XML and create a huge data structure or a huge maze of objects. While at times this is what you have to do or what's most convenient to do, it's not the only solution. And often it's even not the easiest solution. It's quite possible and often quite convenient to process XML in chunks using something like XML::Twig or XML::Record or specify what parts of the XML are you actually interested in and which ones can be ignored, buils a specialized datastructure as you parse the data and (if convenient) handle the chunks with XML::Rules.

Neither will continue eating up memory as the XML grows.

Jenda


Support Denmark! Defend the free world!

I *do* think that something is wrong with XML in terms of resources. Consider the XML and Storable files generated by this script (note that you should lower the number of records if you are short on RAM as the following tests will take near 1GB of memory or so):

use constant RECS => 1000000;
{
    open my $fh, ">/tmp/bla.xml" or die;
    select $fh;
    print "<addresses>\n";
    for (1..RECS) {
    print <<EOF;
  <address>
     <name>John Smith</name>
     <city>London</city>
  </address>
EOF
    }
    print "</addresses>\n";
}

{
    require Storable;
    my @addresses;
    for (1..RECS) {
    push @addresses, { name => "John Smith", city => "London" };
    }
    Storable::nstore(\@addresses, "/tmp/bla.st");
}
[download]

Two mostly equivalent data sources. Now the two benchmarks (I am using tcsh's time command here, showing system, user, elapsed time and maximum memory):

$ ( set time = ( 0 "%U+%S %E %MK" ) ; time perl -MStorable -e 'retriev
+e "/tmp/bla.st"' )
1.980+0.384 0:02.41 193974K
$ ( set time = ( 0 "%U+%S %E %MK" ) ; time perl -MXML::LibXML -e 'XML:
+:LibXML->new->parse_file("/tmp/bla.xml")->documentElement' )
6.037+1.876 0:08.15 643952K
[download]

So naive parsing of XML is much worse in both memory allocation and CPU time than loading the same Storable file. I guess that most other fast serializers like YAML::Syck or JSON::XS will give similar results.