Forem: Nicholas Volkhin

When to Use XmlExtractKit Instead of General XML Tools in PHP

Nicholas Volkhin — Fri, 17 Apr 2026 19:50:21 +0000

One of the easiest ways to make XML work painful in PHP is to start with the wrong question.

A lot of developers ask:

“What is the best XML library for PHP?”

That sounds reasonable, but it is usually the wrong framing.

There is no single best XML tool for every job.

The real question is narrower:

What kind of XML task am I solving?

That matters because XML work in PHP usually falls into very
different categories:

load a small document and read a few values;
manipulate the full document tree;
stream through a large file safely;
extract repeated business records from large XML;
validate or transform XML as XML.

Those are not the same problem, so they should not lead to the same tool choice.

This is the distinction I care about when I use or build XML tooling for PHP.

My package, XmlExtractKit (sbwerewolf/xml-navigator), is not trying to win every XML scenario. It is built for one narrower and very common class of work:

large XML → selected nodes → plain PHP arrays

If that is your actual task, it can be a much better fit than a more general XML tool. If it is not your task, you should probably use something else.

First: what XmlExtractKit is actually for

Before comparing tool categories, it helps to be explicit about the package goal.

XmlExtractKit is built for the boring XML jobs that show up in real systems:

feeds;
imports and exports;
marketplace catalogs;
partner integrations;
ETL pipelines;
SOAP-ish payloads;
legacy endpoints where XML is still the transport format.

In those systems, the application usually does not want to live inside an XML tree.

It usually wants to:

read XML safely;
extract only matching records;
convert them to arrays;
continue with validation, normalization, persistence, or queue publishing.

That is why the package is centered around entry points such as:

FastXmlToArray::prettyPrint();
FastXmlToArray::convert();
FastXmlParser::extractPrettyPrint();
FastXmlParser::extractHierarchy();
XmlElement for traversal of normalized arrays.

So the right comparison is not “Is this package better than every XML library?”

The right comparison is:

Is my task primarily full-document XML work, or is it extraction-oriented application work?

Category 1: small XML, simple reads

Sometimes the job is tiny.

You receive a small XML payload, you need two or three values, and that is it.

Typical cases:

read a config-like XML file;
parse a short API response;
inspect a small test fixture;
run a one-off maintenance script.

For work like that, convenience usually matters more than architecture.

A simple API that loads the whole document can be perfectly fine because:

the file is small;
memory usage is not a concern;
the code is short-lived or trivial;
you do not need a reusable extraction workflow.

This is not where I would reach for XmlExtractKit first.

If the XML is small and the task is simple, the cheapest solution is often the right one.

Category 2: full-document manipulation

There is another class of XML work that is very different from extraction.

Sometimes you really do need the whole document tree.

Examples:

insert or remove nodes across different branches;
reorder sections of the document;
update attributes in multiple places;
build or rewrite XML as XML;
perform document-level transformations.

That is a full-document problem.

In that case, tree-oriented tools and more general XML tooling make much more sense than an extraction-first package.

Why?

Because the center of gravity is different.

You are not trying to stream through repeated records and emit arrays. You are trying to work with the XML document itself as a structured tree.

XmlExtractKit is not trying to be:

an XML editor;
a full XML query language;
a schema validation framework;
a document transformation engine;
a large abstraction layer over every XML concern.

If your real work is document-wide manipulation, use tools designed for document-wide manipulation.

Category 3: large XML, but low-level control is enough

Now we get closer to the problems XmlExtractKit is meant to address.

Suppose the XML file is large.

You know loading it fully is a bad idea, so you switch to XMLReader and stream through it node by node. That is already the correct direction.

For some projects, raw XMLReader is enough.

That is true when:

the extraction rule is very simple;
the script is one-off;
the output shape is minimal;
you do not expect to reuse the logic;
you are comfortable writing and maintaining cursor-level code.

In those cases, a hand-written loop is often fine.

A minimal baseline might look like this:

$reader = XMLReader::open('feed.xml');

while ($reader->read()) {
    if (
        $reader->nodeType === XMLReader::ELEMENT
        && $reader->name === 'offer'
    ) {
        $xml = $reader->readOuterXML();
        $offer = simplexml_load_string($xml);

        $data = [
            'id' => (string) $offer['id'],
            'name' => (string) $offer->name,
            'price' => (string) $offer->price,
        ];

        // process $data
    }
}

$reader->close();

There is nothing wrong with this if the task stays small.

The problem is that many XML integrations do not stay small.

Sooner or later, you accumulate:

more fields;
optional nodes;
attributes and values in different places;
nested structures;
repeated child elements;
normalization rules;
multiple feeds with similar logic;
duplication across projects.

That is the point where low-level control stops being the main concern.

The main concern becomes maintainable extraction.

Category 4: large XML and repeated extraction tasks

This is the sweet spot for XmlExtractKit.

If your task looks like this:

open a large XML stream;
select only matching elements;
convert them to arrays;
hand those arrays to application code;
repeat this pattern across projects;

then a focused extraction toolkit is often the better choice.

The value is not just performance. The value is the shape of the code.

A streaming extraction example with XmlExtractKit looks like this:

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$reader = XMLReader::open('feed.xml');

foreach (
    FastXmlParser::extractPrettyPrint(
        $reader,
        static fn (XMLReader $cursor): bool =>
            $cursor->nodeType === XMLReader::ELEMENT
            && $cursor->name === 'offer'
    ) as $offer
) {
    // process $offer as a plain PHP array
}

$reader->close();

Or, when you want a stable normalized structure for traversal and not just a pretty printed array:

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$reader = XMLReader::open('feed.xml');

foreach (
    FastXmlParser::extractHierarchy(
        $reader,
        static fn (XMLReader $cursor): bool =>
            $cursor->nodeType === XMLReader::ELEMENT
            && $cursor->name === 'offer'
    ) as $offer
) {
    // process normalized hierarchy
}

$reader->close();

This is still a streaming model. It still relies on XMLReader underneath. But the application code is now centered on the real task:

target the elements you care about;
get arrays back;
continue with your business pipeline.

That is the exact problem the package is trying to solve.

Category 5: XML as XML versus XML as transport

This distinction is more important than it sounds.

Some teams work with XML as a primary document format. In that world, XML structure itself is the thing they care about most.

Other teams work with XML only because an external system forces them to.

In those projects, XML is just a transport envelope.

The application does not want to “stay in XML.” It wants to get out of XML as early as possible.

That is usually what happens in:

feed processing;
integration middleware;
import jobs;
back-office syncs;
data ingestion pipelines.

If that describes your system, you will usually benefit more from:

XML stream → selected nodes → arrays

than from a broad, document-centric XML toolkit.

That is why FastXmlToArray::prettyPrint() and FastXmlToArray::convert() are important entry points in XmlExtractKit. They help you turn XML into application-friendly structures early instead of making the rest of your code care about cursor state or DOM traversal.

Category 6: normalized traversal after conversion

There is one more case where a focused extraction/conversion toolkit helps.

Sometimes you do not want a raw “pretty” array for immediate processing. You want a stable internal shape you can traverse predictably.

That is where FastXmlToArray::convert() and XmlElement fit nicely.

For example:

use SbWereWolf\XmlNavigator\Conversion\FastXmlToArray;
use SbWereWolf\XmlNavigator\Navigation\XmlElement;

require_once __DIR__ . '/vendor/autoload.php';

$xml = <<<'XML'
<product sku="KB-1001">
    <name>Mechanical Keyboard</name>
    <price currency="USD">129.90</price>
</product>
XML;

$root = new XmlElement(FastXmlToArray::convert($xml));

$name = $root->pull('name')->current()?->value();
$currency = $root->pull('price')->current()?->get('currency');
$price = $root->pull('price')->current()?->value();

This is useful when you want:

a stable normalized hierarchy;
traversal without re-parsing XML repeatedly;
a representation that is still close to XML structure, but easier to work with than raw cursor logic.

That is another area where a focused toolkit can be more practical than either a tiny one-off parser or a much broader XML stack.

A simple decision matrix

Here is the practical version.

Your task	Best starting point
Small XML, quick read, no reuse expected	A simple full-document approach
Full-document manipulation or transformation	A document/tree-oriented XML tool
Large XML, one-off extraction, you are comfortable with low-level code	Raw `XMLReader`
Large XML, repeated record extraction, output should be arrays	`FastXmlParser::extractPrettyPrint()`
Large XML, repeated record extraction, but you want normalized hierarchy	`FastXmlParser::extractHierarchy()`
Convert XML to arrays for later traversal	`FastXmlToArray::convert()` + `XmlElement`
Convert XML to readable PHP arrays immediately	`FastXmlToArray::prettyPrint()`
You need custom key names in the output structure	`XmlConverter` or `XmlParser`

This is the most useful way to think about the package.

Not as a universal XML winner, but as the right answer for a very specific class of jobs.

When XmlExtractKit is probably the better fit

I would reach for XmlExtractKit when most of these are true:

the XML can be large;
I only need some of the document;
the file contains repeated business records;
I want arrays, not DOM-heavy application code;
I expect similar extraction tasks in more than one project;
I want to keep the rest of the system unaware of XML cursor mechanics.

Typical examples include:

supplier catalog imports;
marketplace feed ingestion;
partner exports;
ETL pipelines;
XML payload normalization before queueing or persistence;
old integrations being consumed by otherwise modern PHP systems.

When a general XML tool is probably the better fit

I would not pick XmlExtractKit first when most of these are true:

the XML is small;
I need full-document traversal and rewriting;
the end result should remain XML, not arrays;
I need schema-heavy or transformation-heavy tooling;
the work is more about XML documents than application data extraction.

That is not a weakness of the package. It is exactly what a focused tool should look like.

A sharp tool is useful because it knows what it is not trying to be.

The practical mistake to avoid

The biggest mistake is to force every XML task into the same mental model.

Developers often do one of these two things:

use a full-document approach for a large extraction problem;
use low-level cursor code for a recurring application-level extraction problem that really wants a better abstraction.

Both create unnecessary cost.

The first creates avoidable memory pressure and awkward processing flows.

The second creates avoidable glue code and long-term maintenance pain.

XmlExtractKit exists in the space between those mistakes.

It is for the case where:

XMLReader is the right low-level engine,
but raw XMLReader is too close to the metal for the amount of
extraction work you actually do.

Conclusion

The useful question is not:

“What is the best XML tool in PHP?”

The useful question is:

“Am I manipulating XML documents, or extracting application data from XML streams?”

If your task is primarily document-centric, general XML tools are the right place to start.

If your task is primarily extraction-centric — especially for large feeds, repeated records, and array-based application pipelines — then XmlExtractKit can be a much better fit.

That is the core positioning of the package:

stream XML, extract only what matters, and keep working with plain PHP arrays.

If that is the problem you keep solving, then a focused tool is often more useful than a general one.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

Benchmark: XMLReader vs XmlExtractKit on a Real Extraction Scenario

Nicholas Volkhin — Fri, 17 Apr 2026 11:48:34 +0000

When people benchmark XML tools, they often compare the wrong things.

They compare a full-document parser to a streaming parser. They compare one tool that returns DOM objects to another that returns arrays. They compare a micro-example that does not resemble production code. Or they publish a time number without showing what work was actually done.

That is not useful.

For real PHP projects, the right benchmark question is usually much
narrower:

If the task is to stream through a large XML feed, extract repeated business records, and turn them into plain PHP arrays, what do I gain by using raw XMLReader directly, and what do I gain by using a focused extraction library such as XmlExtractKit?

That is the comparison I care about.

This article shows how I would benchmark that scenario in a way that is both fair and technically honest.

What the benchmark should measure

For extraction-heavy workloads, “total runtime” is not enough.

A useful benchmark should measure at least four things:

total wall-clock time;
peak memory usage;
time to first useful record;
amount of userland code needed to express the task.

That last one is not a machine metric, but it matters. In many integrations, the long-term cost is not CPU time. It is the amount of extraction glue code you end up carrying from project to project.

The scenario: one realistic extraction task

To keep the comparison fair, both approaches should solve the same task.

Here is the scenario:

the input is a large XML feed;
the feed contains repeated <offer> records;
each offer has nested elements and attributes;
we only care about offer records, not the rest of the document;
the output for each record is a plain PHP array shaped for application use.

That is much closer to a real import or ETL job than an abstract “parse XML” benchmark.

A minimal example of the feed structure looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<catalog generated_at="2026-04-01T08:00:00Z" region="eu">
  <offer id="1001" available="true">
    <sku>KB-1001</sku>
    <name>Mechanical Keyboard</name>
    <brand>Acme</brand>
    <category>Keyboards</category>
    <price currency="USD">129.90</price>
    <stock>14</stock>
  </offer>
  <service id="svc-1">
    <name>Extended Warranty</name>
  </service>
  <offer id="1002" available="false">
    <sku>MS-1002</sku>
    <name>Wireless Mouse</name>
    <brand>Acme</brand>
    <category>Mice</category>
    <price currency="USD">39.90</price>
    <stock>0</stock>
  </offer>
</catalog>

In the benchmark, all implementations should produce records like this:

[
    'external_id' => '1001',
    'available' => true,
    'sku' => 'KB-1001',
    'name' => 'Mechanical Keyboard',
    'brand' => 'Acme',
    'category' => 'Keyboards',
    'price' => '129.90',
    'currency' => 'USD',
    'stock' => '14',
]

That common output shape is important. If the two approaches do different work, the benchmark is meaningless.

What exactly is being compared

I would compare these two implementations:

1. Raw `XMLReader`

This is the “do it yourself” baseline:

move the cursor manually;
detect <offer> nodes;
read attributes and child elements;
assemble arrays by hand;
yield one normalized record at a time.

2. `XmlExtractKit` (`sbwerewolf/xml-navigator`)

This is the extraction-first approach:

still stream through the XML using XMLReader underneath;
use FastXmlParser::extractPrettyPrint() to yield only matching nodes;
normalize the resulting arrays into your application format.

This is the comparison that matters in practice because these two approaches solve the same class of problem: streaming extraction of repeated records.

Why I am not publishing arbitrary numbers here

A benchmark article becomes misleading very quickly when it includes numbers without context.

Runtime depends on all of these things:

PHP version and build;
enabled extensions;
CPU and storage;
XML shape and depth;
number of attributes;
number of repeated child elements;
whether your normalization step is trivial or heavy.

Because of that, I think the honest way to present this benchmark is:

show the exact task;
show both implementations;
show the harness;
explain what to measure;
tell readers how to interpret the results.

That way the article stays useful even when the raw numbers differ from machine to machine.

Step 1: generate a reproducible XML fixture

For a benchmark, hand-written miniature XML is not enough.

You want a generated fixture with many repeated records so that the streaming behavior becomes visible.

Here is a simple generator:

<?php

declare(strict_types=1);

function generateCatalogFixture(string $path, int $offers = 9999): void
{
    $fh = fopen($path, 'wb');

    if ($fh === false) {
        throw new RuntimeException(
            'Cannot open fixture file for writing.'
        );
    }

    $date = date('Y-m-d');
    fwrite($fh, "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n");
    fwrite($fh, "<catalog generated_at=\"$date\" region=\"eu\">\n");

    for ($i = 1; $i <= $offers; $i++) {
        $available = $i % 7 === 0 ? 'false' : 'true';
        $brand = 'Brand-' . ($i % 13);
        $category = 'Category-' . ($i % 9);
        $price = number_format(10 + ($i % 1000) / 10, 2, '.', '');
        $stock = (string) ($i % 25);

        fwrite($fh, "  <offer id=\"{$i}\" available=\"{$available}\">\n");
        fwrite($fh, "    <sku>SKU-{$i}</sku>\n");
        fwrite($fh, "    <name>Product {$i}</name>\n");
        fwrite($fh, "    <brand>{$brand}</brand>\n");
        fwrite($fh, "    <category>{$category}</category>\n");
        fwrite($fh, "    <price currency=\"USD\">{$price}</price>\n");
        fwrite($fh, "    <stock>{$stock}</stock>\n");
        fwrite($fh, "  </offer>\n");

        if ($i % 1000 === 0) {
            fwrite($fh, "  <service id=\"svc-{$i}\"><name>Warranty</name></service>\n");
        }
    }

    fwrite($fh, "</catalog>\n");
    fclose($fh);
}

This gives both implementations identical input and enough repeated records to make the comparison meaningful.

Step 2: the raw XMLReader baseline

The baseline should be direct and honest. It should not be intentionally ugly, but it should reflect the kind of code people really end up writing when they solve the problem manually.

Here is one way to do that:

<?php

declare(strict_types=1);

/**
 * @return Generator<int, array<string, mixed>>
 */
function iterateOffersWithXmlReader(string $path): Generator
{
    $reader = XMLReader::open($path);

    if ($reader === false) {
        throw new RuntimeException('Cannot open XML file.');
    }

    try {
        while ($reader->read()) {
            if (
                $reader->nodeType !== XMLReader::ELEMENT
                || $reader->name !== 'offer'
            ) {
                continue;
            }

            $depth = $reader->depth;

            $offer = [
                'external_id' => $reader->getAttribute('id') ?? '',
                'available' => ($reader->getAttribute('available') ?? '') === 'true',
                'sku' => '',
                'name' => '',
                'brand' => '',
                'category' => '',
                'price' => '',
                'currency' => '',
                'stock' => '0',
            ];

            while ($reader->read()) {
                if (
                    $reader->nodeType === XMLReader::END_ELEMENT
                    && $reader->name === 'offer'
                    && $reader->depth === $depth
                ) {
                    break;
                }

                if ($reader->nodeType !== XMLReader::ELEMENT) {
                    continue;
                }

                switch ($reader->name) {
                    case 'sku':
                        $offer['sku'] = $reader->readString();
                        break;

                    case 'name':
                        $offer['name'] = $reader->readString();
                        break;

                    case 'brand':
                        $offer['brand'] = $reader->readString();
                        break;

                    case 'category':
                        $offer['category'] = $reader->readString();
                        break;

                    case 'price':
                        $offer['currency'] = $reader->getAttribute('currency') ?? '';
                        $offer['price'] = $reader->readString();
                        break;

                    case 'stock':
                        $offer['stock'] = $reader->readString();
                        break;
                }
            }

            yield $offer;
        }
    } finally {
        $reader->close();
    }
}

There is nothing wrong with this code. In fact, for some one-off jobs it is a perfectly reasonable solution.

But it already illustrates the tradeoff:

manual cursor handling;
explicit depth management;
hand-written field extraction;
record assembly mixed with traversal logic.

That is exactly what I want the benchmark to capture.

Step 3: the XmlExtractKit implementation

Now compare it with the extraction-first version.

XmlExtractKit still uses the streaming model, but it moves the code closer to the business task: extract matching nodes, then normalize them.

<?php

declare(strict_types=1);

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

/**
 * @param array<string, mixed> $node
 * @return array<string, mixed>
 */
function normalizeOffer(array $node): array
{
    $offer = $node['offer'] ?? [];
    $attributes = $offer['@attributes'] ?? [];
    $price = $offer['price'] ?? [];
    $priceAttributes = is_array($price) ? ($price['@attributes'] ?? []) : [];

    return [
        'external_id' => ($attributes['id'] ?? ''),
        'available' => (($attributes['available'] ?? '')) === 'true',
        'sku' => ($offer['sku'] ?? ''),
        'name' => ($offer['name'] ?? ''),
        'brand' => ($offer['brand'] ?? ''),
        'category' => ($offer['category'] ?? ''),
        'price' => is_array($price) ? ($price['@value'] ?? '') : $price,
        'currency' => ($priceAttributes['currency'] ?? ''),
        'stock' => ($offer['stock'] ?? '0'),
    ];
}

/**
 * @return Generator<int, array<string, mixed>>
 */
function iterateOffersWithXmlExtractKit(string $path): Generator
{
    $reader = XMLReader::open($path);

    if ($reader === false) {
        throw new RuntimeException('Cannot open XML file.');
    }

    try {
        foreach (
            FastXmlParser::extractPrettyPrint(
                $reader,
                static fn (XMLReader $cursor): bool =>
                    $cursor->nodeType === XMLReader::ELEMENT
                    && $cursor->name === 'offer'
            ) as $node
        ) {
            yield normalizeOffer($node);
        }
    } finally {
        $reader->close();
    }
}

The normalization step is explicit in both versions, which is good. The difference is where the complexity lives.

With raw XMLReader, traversal and record assembly are tightly coupled.

With XmlExtractKit, traversal stays streaming-based, but the extraction phase is lifted into a more reusable form.

Step 4: use a benchmark harness that measures the right things

A benchmark harness should consume the records fully, otherwise the result is misleading.

It should also record the time to the first yielded record, not just the final completion time.

Here is a simple harness:

<?php

declare(strict_types=1);

/**
 * @param callable(): iterable<array<string, mixed>> $factory
 * @return array<string, int|float>
 */
function benchmarkExtraction(callable $factory): array
{
    gc_collect_cycles();

    if (function_exists('memory_reset_peak_usage')) {
        memory_reset_peak_usage();
    }

    $startedAt = hrtime(true);
    $firstRecordMs = null;
    $count = 0;
    $checksum = 0;

    foreach ($factory() as $record) {
        $count++;
        $checksum += strlen((string) ($record['external_id'] ?? ''));

        if ($firstRecordMs === null) {
            $firstRecordMs = (hrtime(true) - $startedAt) / 1_000_000;
        }
    }

    $elapsedMs = (hrtime(true) - $startedAt) / 1_000_000;
    $peakMb = memory_get_peak_usage(true) / 1024 / 1024;

    return [
        'records' => $count,
        'checksum' => $checksum,
        'first_record_ms' => $firstRecordMs ?? 0.0,
        'elapsed_ms' => $elapsedMs,
        'peak_memory_mb' => $peakMb,
    ];
}

And here is how you would run it:

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

$fixture = __DIR__ . '/catalog-benchmark.xml';
generateCatalogFixture($fixture, 50000);

$xmlReaderResult = benchmarkExtraction(
    static fn (): iterable => iterateOffersWithXmlReader($fixture)
);

$xmlExtractKitResult = benchmarkExtraction(
    static fn (): iterable => iterateOffersWithXmlExtractKit($fixture)
);

var_export([
    'xmlreader' => $xmlReaderResult,
    'xmlextractkit' => $xmlExtractKitResult,
]);

That is enough to produce a reproducible benchmark on your own machine.

What I would expect to see

I would not assume that one implementation wins every metric.

That is exactly why this comparison is interesting.

Peak memory

If both solutions are truly streaming and process one record at a time, peak memory should stay controlled in both implementations.

If one of them starts materializing too much intermediate state, this metric will reveal it quickly.

Time to first record

This is one of the most underrated metrics for XML extraction workloads.

If your pipeline can start processing useful data almost immediately, that is a real engineering advantage. It matters for imports, progress reporting, partial processing, and backpressure-aware systems.

Total runtime

This matters, but it should not dominate the interpretation.

A lower-level implementation may sometimes squeeze out a small performance advantage. But if that advantage comes with much more traversal glue, branching, and duplicated code, it may not be the better engineering choice.

Userland code size and complexity

This is not a synthetic concern.

In production codebases, a solution that is 5% faster but significantly harder to review, extend, and reuse is often the more expensive solution.

That is why I would always report both machine metrics and code-shape metrics side by side.

What would make the benchmark unfair

A benchmark like this becomes unreliable very quickly if you do any of the following:

compare different output shapes;
parse different XML structures;
make one side do more normalization work;
compare a streaming solution to a full-document solution;
benchmark tiny files that do not stress the streaming model;
omit the code and only publish the result table.

The point is not to “win.”

The point is to understand the tradeoff for a specific extraction task.

My interpretation of this comparison

This is how I would read the result after running the benchmark.

If raw XMLReader is slightly faster but the difference is small, I would still strongly consider XmlExtractKit for repeated integration work because the extraction code is easier to reason about and easier to reuse.

If XmlExtractKit comes out close on runtime and similar on peak memory, that is already a strong result for the library because it means the higher-level extraction model is not buying convenience at an unreasonable systems cost.

If the XML task is extremely narrow and unlikely to be reused, raw XMLReader may still be the right answer.

But if the workload looks like real feed processing and the extraction pattern shows up again and again, the benefit of moving from cursor choreography to extraction-oriented code becomes very tangible.

Conclusion

The most useful XML benchmark is not “which parser is fastest in the abstract.”

It is:

for this exact extraction task, on this XML shape, with this output model, what do I gain in runtime, memory, first-record latency, and maintainability?

That is why I think raw XMLReader vs XmlExtractKit is the comparison worth making.

They belong to the same real-world decision point:

write the traversal and extraction layer yourself;
or keep the streaming model but use a focused library to reduce the
amount of glue code.

For large XML feeds in modern PHP, that is a benchmark that actually tells you something useful.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

Processing Supplier and Marketplace XML Feeds in PHP

Nicholas Volkhin — Thu, 16 Apr 2026 09:50:34 +0000

Supplier and marketplace integrations are one of the places where XML refuses to die.

That is not a complaint. It is just the shape of the problem.

If you build import pipelines, catalog sync jobs, price updates, availability updates, or partner data bridges, sooner or later you will meet an XML feed that contains the data you need in a format your application does not really want.

In those situations, the most important design decision is usually not about XML itself.

It is about the processing model.

Do you treat the feed as a document that your application should “work with”? Or do you treat it as an external transport format that should be scanned, filtered, converted, normalized, and handed off to the rest of your pipeline as plain PHP data?

For supplier and marketplace feeds, I strongly prefer the second model.

That is the approach behind XmlExtractKit, published as sbwerewolf/xml-navigator.

The real shape of feed-processing work

When people hear “XML parsing,” the task can sound abstract.

Supplier and marketplace feeds are not abstract.

They usually look more like this:

a large file with repeated business records;
products, offers, items, categories, stock entries, prices, or media blocks;
partial updates, optional fields, nested elements, repeated child tags, and attributes;
a downstream pipeline that wants arrays, validated records, database writes, or queue jobs.

That means the actual engineering task is usually not:

“Parse XML.”

It is:

“Extract repeated records from an external feed and transform them into a predictable internal format.”

That framing leads to much better implementation choices.

What makes feeds different from small XML documents

Small XML documents are often fine with convenient full-document APIs.

Feeds are different for a few reasons.

1. They are repetitive by nature

A feed usually contains the same business structure again and again:

<offer>
<product>
<item>
<entry>

That is a strong signal that you should process the XML as a sequence of records, not as one big tree you want to keep in memory.

2. You rarely need everything

A typical import job does not need every element in the feed.

It may only need:

the offer identifier;
availability;
price;
currency;
category;
a few images;
update timestamps;
one or two custom attributes.

The rest is often irrelevant for the current pipeline step.

3. The output is almost never “more XML”

Your import layer usually wants:

associative arrays;
normalized field values;
database rows;
JSON payloads;
DTOs;
queue messages.

That is why feed work is usually an extraction and normalization problem, not an XML-manipulation problem.

A representative feed example

Here is a simplified feed structure that is close to what many supplier and marketplace pipelines deal with:

<?xml version="1.0" encoding="UTF-8"?>
<catalog generated_at="2026-04-01T08:00:00Z" region="eu">
  <offer id="1001" available="true">
    <sku>KB-1001</sku>
    <name>Mechanical Keyboard</name>
    <brand>Acme</brand>
    <category>Keyboards</category>
    <price currency="USD">129.90</price>
    <oldprice currency="USD">149.90</oldprice>
    <picture>https://cdn.example.test/kb-1001-front.jpg</picture>
    <picture>https://cdn.example.test/kb-1001-side.jpg</picture>
    <stock>14</stock>
  </offer>
  <offer id="1002" available="false">
    <sku>MS-1002</sku>
    <name>Wireless Mouse</name>
    <brand>Acme</brand>
    <category>Mice</category>
    <price currency="USD">39.90</price>
    <picture>https://cdn.example.test/ms-1002.jpg</picture>
    <stock>0</stock>
  </offer>
</catalog>

This is already enough to illustrate the real shape of the work.

The import pipeline usually does not want to keep this XML structure around.

It wants to turn each <offer> into something like:

[
    'external_id' => '1001',
    'sku' => 'KB-1001',
    'name' => 'Mechanical Keyboard',
    'brand' => 'Acme',
    'category' => 'Keyboards',
    'price' => '129.90',
    'currency' => 'USD',
    'old_price' => '149.90',
    'available' => true,
    'stock' => 14,
    'pictures' => [
        'https://cdn.example.test/kb-1001-front.jpg',
        'https://cdn.example.test/kb-1001-side.jpg',
    ],
]

That is the internal target.

Once you are clear about that, the XML side becomes much easier to reason about.

The two stages that matter most

For feed pipelines, I think it helps to split the work into two explicit stages.

Stage 1: extraction

This is where you identify the repeated record you care about and convert it into a predictable PHP structure.

Stage 2: normalization

This is where you adapt that structure to your own application model:

rename fields;
cast values;
collapse optional fields;
map categories;
validate currency or stock rules;
prepare records for persistence or messaging.

Trying to collapse these two stages into one giant parsing function usually makes the code harder to maintain.

Why streaming is such a good fit for feeds

Supplier and marketplace feeds are one of the best use cases for streaming XML traversal.

The reasons are practical:

files can become large over time;
records are naturally repeated;
each record can often be processed independently;
you usually do not need the whole document tree;
early filtering is valuable.

This is exactly where XMLReader and extraction-first libraries built on top of it become useful.

With XmlExtractKit, I usually approach these feeds as “find repeated offers and turn them into arrays.”

Here is a streaming extraction example using FastXmlParser::extractPrettyPrint():

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$uri = tempnam(sys_get_temp_dir(), 'supplier-feed-');

file_put_contents($uri, <<<'XML'
<?xml version="1.0" encoding="UTF-8"?>
<catalog generated_at="2026-04-01T08:00:00Z" region="eu">
  <offer id="1001" available="true">
    <sku>KB-1001</sku>
    <name>Mechanical Keyboard</name>
    <brand>Acme</brand>
    <category>Keyboards</category>
    <price currency="USD">129.90</price>
    <picture>https://cdn.example.test/kb-1001-front.jpg</picture>
    <picture>https://cdn.example.test/kb-1001-side.jpg</picture>
    <stock>14</stock>
  </offer>
  <service id="svc-1">
    <name>Extended Warranty</name>
  </service>
  <offer id="1002" available="false">
    <sku>MS-1002</sku>
    <name>Wireless Mouse</name>
    <brand>Acme</brand>
    <category>Mice</category>
    <price currency="USD">39.90</price>
    <picture>https://cdn.example.test/ms-1002.jpg</picture>
    <stock>0</stock>
  </offer>
</catalog>
XML);

$reader = XMLReader::open($uri);

if ($reader === false) {
    throw new RuntimeException('Cannot open XML feed.');
}

$offers = FastXmlParser::extractPrettyPrint(
    $reader,
    static fn (XMLReader $cursor): bool =>
        $cursor->nodeType === XMLReader::ELEMENT
        && $cursor->name === 'offer'
);

foreach ($offers as $offer) {
    echo json_encode(
        $offer,
        JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
    ) . PHP_EOL;
}

$reader->close();
unlink($uri);

That extraction result is already close to what the rest of the application needs.

It is still XML-derived data, but it is no longer trapped in XML traversal logic.

Why readable arrays help so much in feed work

In feed-processing pipelines, readability is not cosmetic.

It directly affects how quickly you can:

inspect bad records;
log partial failures;
test normalization rules;
compare incoming and outgoing payloads;
reason about optional fields;
support multiple partner formats.

That is why array output is so practical.

For example, one extracted <offer> might look like this after extractPrettyPrint():

[
    'offer' => [
        '@attributes' => [
            'id' => '1001',
            'available' => 'true',
        ],
        'sku' => 'KB-1001',
        'name' => 'Mechanical Keyboard',
        'brand' => 'Acme',
        'category' => 'Keyboards',
        'price' => [
            '@value' => '129.90',
            '@attributes' => [
                'currency' => 'USD',
            ],
        ],
        'picture' => [
            'https://cdn.example.test/kb-1001-front.jpg',
            'https://cdn.example.test/kb-1001-side.jpg',
        ],
        'stock' => '14',
    ],
]

That is a much better input for normalization code than a half-processed XML cursor state.

The normalization step is where your business rules belong

Once the feed record is in array form, you can normalize it with ordinary PHP code.

For example:

/**
 * @param array<string, mixed> $record
 * @return array<string, mixed>
 */
function normalizeOffer(array $record): array
{
    $offer = $record['offer'];

    $pictures = $offer['picture'] ?? [];
    if (! is_array($pictures)) {
        $pictures = [$pictures];
    }

    return [
        'external_id' => $offer['@attributes']['id'] ?? null,
        'available' => ($offer['@attributes']['available'] ?? 'false') === 'true',
        'sku' => $offer['sku'] ?? null,
        'name' => $offer['name'] ?? null,
        'brand' => $offer['brand'] ?? null,
        'category' => $offer['category'] ?? null,
        'price' => $offer['price']['@value'] ?? null,
        'currency' => $offer['price']['@attributes']['currency'] ?? null,
        'stock' => isset($offer['stock']) ? (int) $offer['stock'] : null,
        'pictures' => array_values(array_filter($pictures, 'is_string')),
    ];
}

This is where business logic belongs.

Not in low-level XML traversal. Not in cursor movement. Not in string fragments.

A clean import architecture keeps those concerns separate.

Repeated tags, attributes, and optional fields are not edge cases

In feed processing, these are normal conditions:

multiple images;
optional old price;
empty stock fields;
attributes that carry business meaning;
tags that are present for some suppliers and absent for others.

That is another reason I prefer extraction to arrays early.

Once the record is in a stable PHP structure, handling these cases becomes straightforward.

You can:

default missing fields;
cast types;
merge repeated tags into lists;
strip noise;
build validation rules around familiar array shapes.

One feed is manageable. Ten feeds expose architecture problems

A lot of parsing approaches look acceptable when there is only one partner.

The trouble begins when the system grows:

supplier A sends offer;
supplier B sends item;
marketplace C adds nested media blocks;
another feed uses attributes where the previous one used child elements;
one integration sends a full nightly catalog;
another sends partial incremental updates.

At that point, the quality of your processing model matters much more than the convenience of a single parser call.

The goal is not just “parse this file.”

The goal is to build a repeatable pattern:

extract repeated records;
convert them into stable PHP structures;
normalize them into your domain shape;
pass them downstream.

That pattern scales much better than spreading XML handling rules throughout the codebase.

A useful split for real projects

For supplier and marketplace XML feeds, I think the cleanest split is this:

Integration edge

read the XML stream;
extract only target records;
convert them into arrays.

Normalization layer

cast and validate fields;
reconcile naming differences;
apply partner-specific mapping rules;
create consistent internal records.

Application layer

persist catalog data;
emit events;
update search indexes;
enqueue downstream jobs.

This keeps XML where it belongs: at the edge.

When a full-document approach is still fine

Not every feed needs streaming.

If the XML is small and the structure is simple, a full-document approach may be completely acceptable.

But supplier and marketplace integrations tend to drift in one direction over time:

more records;
more nested data;
more optional fields;
more partner variants;
more operational pressure.

That is why an extraction-first model is often the safer default.

It is not about premature optimization.

It is about choosing a processing pattern that continues to work when the feed stops being toy-sized.

Conclusion

Supplier and marketplace XML feeds are rarely difficult because XML is mysterious.

They are difficult because they combine repetition, size, optional structure, external control, and business-specific normalization rules.

That is why I think the most productive way to handle them in PHP is:

stream the feed when needed;
extract repeated records instead of loading everything;
convert XML into plain arrays early;
keep normalization and business rules outside low-level XML traversal.

That is the workflow I wanted from XmlExtractKit.

Not a giant XML abstraction layer. Not an attempt to make XML pleasant.

Just a practical path from external XML feeds to application-ready PHP data.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

Converting XML Feeds to Plain PHP Arrays in Modern PHP

Nicholas Volkhin — Wed, 15 Apr 2026 19:20:07 +0000

When people say they need to “work with XML” in PHP, that phrasing is often already slightly misleading.

In most business applications, XML is not the format you actually want to keep around.

It is just the format you received.

A supplier feed arrives as XML. A marketplace export arrives as XML. A partner integration still speaks XML. A legacy endpoint responds with XML. But once the data enters your application, the rest of the code usually does not want an XML tree.

It wants ordinary PHP data.

That is the practical framing I use in modern PHP projects:

XML is usually a transport format. The real goal is to convert the useful parts into plain PHP arrays as early as possible.

Once you look at the problem this way, a lot of implementation decisions become much clearer.

Why arrays are usually the real target

Most application code does not benefit from carrying XML semantics deeper into the stack than necessary.

Your service layer, validation logic, queue payloads, DTO mappers, logging, database writers, and JSON APIs usually work best with plain associative arrays.

That means the useful pipeline often looks like this:

XML feed → extracted records → plain PHP arrays → validation / normalization / persistence

This is one of the reasons I built XmlExtractKit for PHP, published as sbwerewolf/xml-navigator.

The package is designed around a very boring but very common need:

take XML input;
extract the records that matter;
get plain PHP arrays back;
keep the rest of the application free from low-level XML handling.

That is a better fit for modern application code than dragging cursor
logic or DOM structures through multiple layers.

A typical XML feed problem

Suppose a partner sends you a product feed like this:

<?xml version="1.0" encoding="UTF-8"?>
<feed generated_at="2026-03-28T09:00:00Z">
  <offer id="206111" available="true">
    <name>USB-C Dock</name>
    <price currency="USD">129.90</price>
    <picture>https://cdn.example.test/1.jpg</picture>
    <picture>https://cdn.example.test/2.jpg</picture>
  </offer>
</feed>

What does the rest of your application usually want from this?

Not an XML tree.

Usually something closer to this:

[
    'feed' => [
        '@attributes' => [
            'generated_at' => '2026-03-28T09:00:00Z',
        ],
        'offer' => [
            '@attributes' => [
                'id' => '206111',
                'available' => 'true',
            ],
            'name' => 'USB-C Dock',
            'price' => [
                '@value' => '129.90',
                '@attributes' => [
                    'currency' => 'USD',
                ],
            ],
            'picture' => [
                'https://cdn.example.test/1.jpg',
                'https://cdn.example.test/2.jpg',
            ],
        ],
    ],
]

That structure is already much more useful.

You can serialize it, validate it, map it to a DTO, send it to a queue, store it, or normalize it further.

That is why I think “XML to arrays” is a much more practical category than “XML processing” for a lot of real PHP work.

The first decision: readable arrays or normalized hierarchy

One thing I like about XmlExtractKit is that it makes this tradeoff
explicit.

There are two main output styles:

readable output, via FastXmlToArray::prettyPrint();
normalized output, via FastXmlToArray::convert().

They solve related but different problems.

Readable output: best for application code

If your goal is to move XML into ordinary PHP code quickly, readable arrays are usually the right default.

Here is a direct conversion example:

use SbWereWolf\XmlNavigator\Conversion\FastXmlToArray;

require_once __DIR__ . '/vendor/autoload.php';

$xml = <<<'XML'
<feed generated_at="2026-03-28T09:00:00Z">
  <offer id="206111" available="true">
    <name>USB-C Dock</name>
    <price currency="USD">129.90</price>
    <picture>https://cdn.example.test/1.jpg</picture>
    <picture>https://cdn.example.test/2.jpg</picture>
  </offer>
</feed>
XML;

$result = FastXmlToArray::prettyPrint($xml);

echo json_encode(
    $result,
    JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
);

Output:

{
  "feed": {
    "@attributes": {
      "generated_at": "2026-03-28T09:00:00Z"
    },
    "offer": {
      "@attributes": {
        "id": "206111",
        "available": "true"
      },
      "name": "USB-C Dock",
      "price": {
        "@value": "129.90",
        "@attributes": {
          "currency": "USD"
        }
      },
      "picture": [
        "https://cdn.example.test/1.jpg",
        "https://cdn.example.test/2.jpg"
      ]
    }
  }
}

This output format is intentionally convenient.

It is useful when you want to:

return a structured payload from a service;
serialize data to JSON;
inspect logs or debug dumps;
pass a transformed record into validation or normalization code;
feed the result into downstream application logic.

The array shape follows a few simple rules:

attributes go under @attributes;
element text goes under @value when attributes are also present;
repeated child tags become indexed arrays.

That is exactly the kind of shape that works well in typical modern PHP code.

When normalized output is the better choice

Readable output is great for many pipelines, but sometimes you want a structure that is more explicit and more stable for traversal.

That is where FastXmlToArray::convert() comes in.

Instead of optimizing for immediate readability, it gives each node the same predictable contract:

n = element name;
v = direct value;
a = attributes;
s = child sequence.

Here is the same feed converted into normalized hierarchy form:

use SbWereWolf\XmlNavigator\Conversion\FastXmlToArray;

require_once __DIR__ . '/vendor/autoload.php';

$xml = <<<'XML'
<feed generated_at="2026-03-28T09:00:00Z">
  <offer id="206111" available="true">
    <name>USB-C Dock</name>
    <price currency="USD">129.90</price>
    <picture>https://cdn.example.test/1.jpg</picture>
    <picture>https://cdn.example.test/2.jpg</picture>
  </offer>
</feed>
XML;

$result = FastXmlToArray::convert($xml);

var_export($result);

Output:

array (
  'n' => 'feed',
  'a' =>
  array (
    'generated_at' => '2026-03-28T09:00:00Z',
  ),
  's' =>
  array (
    0 =>
    array (
      'n' => 'offer',
      'a' =>
      array (
        'id' => '206111',
        'available' => 'true',
      ),
      's' =>
      array (
        0 =>
        array (
          'n' => 'name',
          'v' => 'USB-C Dock',
        ),
        1 =>
        array (
          'n' => 'price',
          'v' => '129.90',
          'a' =>
          array (
            'currency' => 'USD',
          ),
        ),
        2 =>
        array (
          'n' => 'picture',
          'v' => 'https://cdn.example.test/1.jpg',
        ),
        3 =>
        array (
          'n' => 'picture',
          'v' => 'https://cdn.example.test/2.jpg',
        ),
      ),
    ),
  ),
)

This output is not as immediately pleasant to read, but it is very useful when you care about consistent traversal and adapters.

That becomes valuable when you want to:

build wrappers on top of a stable node contract;
walk the structure programmatically;
distinguish explicitly between element names, values, attributes, and children;
create internal tooling that should not depend on the shape of one specific XML document.

In other words, prettyPrint() is great when the output is the destination. convert() is great when the output is an intermediate representation.

Arrays are only useful if they are easy to navigate

Sometimes a plain array is enough.

Sometimes you want something slightly higher-level without going back to low-level XML logic.

That is where XmlElement fits very nicely.

You can take the normalized hierarchy returned by FastXmlToArray::convert() and wrap it in XmlElement for convenient traversal.

Here is a simple example:

use SbWereWolf\XmlNavigator\Conversion\FastXmlToArray;
use SbWereWolf\XmlNavigator\Navigation\XmlElement;

require_once __DIR__ . '/vendor/autoload.php';

$xml = <<<'XML'
<catalog region="eu">
  <offer id="1001" available="true">
    <name>Keyboard</name>
    <tag>office</tag>
    <tag>usb</tag>
  </offer>
</catalog>
XML;

$root = new XmlElement(FastXmlToArray::convert($xml));
$offer = $root->pull('offer')->current();

echo $root->name() . PHP_EOL;
echo $root->get('region') . PHP_EOL;
echo ($root->hasElement('offer') ? 'yes' : 'no') . PHP_EOL;

foreach ($offer->attributes() as $attribute) {
    echo $attribute->name() . '=' . $attribute->value() . PHP_EOL;
}

$tagValues = array_map(
    static fn (XmlElement $tag): string => $tag->value(),
    $offer->elements('tag')
);

var_export($tagValues);

This is a useful middle ground.

The data is still array-based and application-friendly, but navigation becomes clearer:

name() for the current element name;
get() for attributes;
hasElement() to check for children;
pull() or elements() to navigate down the structure.

This is often cleaner than passing around raw nested arrays with hardcoded indexes everywhere.

Why this matters in feed processing

Feed processing is usually repetitive.

You receive XML, extract records, normalize them, validate them, and push them further into the pipeline.

That means the most practical XML question is often not:

“Which library can represent XML most completely?”

It is:

“Which approach gets me from XML to application-ready records with the least friction?”

That is why plain PHP arrays are such a strong target format for feed work.

They are easy to:

inspect;
serialize;
compare in tests;
transform;
validate;
store;
hand off to other services.

By contrast, keeping XML structures alive deep into the business layer usually increases the amount of incidental complexity.

What about large feeds?

For large XML feeds, the array-conversion story should not force you back into full-document loading.

This is where the streaming entry points matter.

If you want readable application-friendly output directly from selected nodes in a large document, there is FastXmlParser::extractPrettyPrint().

Here is a compact example:

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$uri = tempnam(sys_get_temp_dir(), 'xml-extract-kit-');
file_put_contents($uri, <<<'XML'
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
  <offer id="1">
    <name>Keyboard</name>
    <price>49.90</price>
  </offer>
  <service id="s-1">
    <name>Warranty</name>
  </service>
  <offer id="2">
    <name>Mouse</name>
    <price>19.90</price>
  </offer>
</catalog>
XML);

$reader = XMLReader::open($uri);

if ($reader === false) {
    throw new RuntimeException('Cannot open XML file.');
}

$offers = FastXmlParser::extractPrettyPrint(
    $reader,
    static fn (XMLReader $cursor): bool => $cursor->name === 'offer'
);

foreach ($offers as $offer) {
    echo json_encode(
        $offer,
        JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
    ) . PHP_EOL;
}

$reader->close();
unlink($uri);

That gives you the same extraction-first workflow as in the earlier articles, but with output that is already convenient for application
code.

So the package is not making you choose between streaming and readable arrays.

It is designed to give you both.

A useful decision rule

For practical PHP work, I think the following rule holds up well:

use prettyPrint() when you want readable arrays now;
use convert() when you want a stable internal node model;
use XmlElement when you want to traverse normalized arrays more comfortably;
use extractPrettyPrint() when the XML is large and you only want selected records in readable form;
use extractHierarchy() when the XML is large and you want selected records in normalized form.

This is a much more actionable way to think about XML work than asking for a single “best XML library.”

One more practical point: XML should not leak everywhere

I think one of the easiest mistakes in integration code is to let transport concerns leak too far.

A feed arrives as XML, so suddenly everything downstream starts thinking in XML terms:

node trees;
cursor state;
fragment parsing;
nested traversal rules.

That is usually unnecessary.

A much cleaner architecture is:

receive XML;
convert it into a representation your application actually likes;
keep business logic focused on plain PHP data.

This is exactly why array-first conversion is so useful. It creates
a boundary.

The XML stays near the integration edge, where it belongs.

Conclusion

In modern PHP projects, XML is often not the thing you want to work with. It is the thing you need to get past.

That is why converting XML feeds to plain PHP arrays is such a practical strategy.

Readable arrays are ideal when you want immediate application-friendly data. Normalized arrays are ideal when you want a stable traversal model. And for large feeds, streaming extraction lets you keep the memory-safe approach without sacrificing useful output.

That combination is what I wanted from XmlExtractKit:

XML as input;
arrays as output;
streaming when needed;
low friction in the application layer.

If that is the kind of PHP XML workflow you deal with, sbwerewolf/xml-navigator is built for exactly that use case.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

XMLReader vs XmlExtractKit for Real XML Extraction Tasks in PHP

Nicholas Volkhin — Tue, 14 Apr 2026 18:50:24 +0000

When PHP developers compare XML approaches, the comparison often starts in the wrong place.

It usually becomes a vague question like this:

"What is the best XML library for PHP?"

That is too broad to be useful.

In real projects, the question is usually much narrower:

I have a large XML file;
it contains repeated business records;
I only need some of those records;
I want application-friendly PHP data, not a full in-memory XML tree.

That is not a general XML problem.

It is an extraction task.

And for this kind of work, the most honest comparison is often not between two third-party packages. It is between:

raw XMLReader, where you write the extraction logic yourself;
a focused extraction toolkit, where the streaming model stays
the same but the glue code becomes reusable.

In my case, that focused toolkit is XmlExtractKit, published as sbwerewolf/xml-navigator.

This article compares both approaches on the same practical task.

The task

Suppose we have a large XML feed that contains repeated <offer> records, mixed with other node types that we do not care about.

We want to extract each offer into a PHP array with a shape like this:

[
    'id' => '1001',
    'available' => true,
    'name' => 'Keyboard',
    'price' => 49.90,
    'currency' => 'USD',
]

Here is the sample XML:

<?xml version="1.0" encoding="UTF-8"?>
<catalog>
  <offer id="1001" available="true">
    <name>Keyboard</name>
    <price currency="USD">49.90</price>
  </offer>
  <service id="s-1">
    <name>Warranty</name>
  </service>
  <offer id="1002" available="false">
    <name>Mouse</name>
    <price currency="USD">19.90</price>
  </offer>
</catalog>

This is a simple example, but it is representative of a lot of real XML integration work: repeated nodes, some attributes, some nested values, and other elements that should be ignored.

Option 1: raw XMLReader

The low-level memory-safe baseline in PHP is XMLReader.

That makes it the right foundation for large-file extraction.

Here is one way to solve the task with plain XMLReader and a small
amount of helper parsing:

$reader = new XMLReader();

if (! $reader->open('feed.xml')) {
    throw new RuntimeException('Cannot open XML file.');
}

$rows = [];

while ($reader->read()) {
    if (
        $reader->nodeType !== XMLReader::ELEMENT
        || $reader->name !== 'offer'
    ) {
        continue;
    }

    $offerXml = $reader->readOuterXML();
    $offer = simplexml_load_string($offerXml);

    if ($offer === false) {
        continue;
    }

    $rows[] = [
        'id' => (string) $offer['id'],
        'available' => ((string) $offer['available']) === 'true',
        'name' => (string) $offer->name,
        'price' => (float) $offer->price,
        'currency' => (string) $offer->price['currency'],
    ];
}

$reader->close();

var_export($rows);

Output:

array (
  0 =>
  array (
    'id' => '1001',
    'available' => true,
    'name' => 'Keyboard',
    'price' => 49.9,
    'currency' => 'USD',
  ),
  1 =>
  array (
    'id' => '1002',
    'available' => false,
    'name' => 'Mouse',
    'price' => 19.9,
    'currency' => 'USD',
  ),
)

This is a perfectly valid solution.

It is memory-safe in the important sense: we are not loading the whole XML document into memory. We are moving through the stream and extracting matching nodes.

For a one-off task, this may be enough.

But there are tradeoffs.

What the raw XMLReader version costs you

The raw XMLReader version works, but its cost is not obvious when the example is this small.

The real cost shows up later:

matching logic has to be repeated or abstracted;
field extraction rules are embedded directly in the loop;
nested XML handling becomes more verbose;
attributes and text values require repeated manual decisions;
optional fields quickly add conditionals;
the same extraction pattern gets reimplemented across projects.

This is the critical point: the issue is not whether XMLReader is capable. It absolutely is.

The issue is whether low-level cursor code is the right place to keep business extraction logic once the project grows beyond a toy example.

Option 2: XmlExtractKit on top of XMLReader

Now let us solve the same extraction task using XmlExtractKit.

The important thing to understand is that the streaming model does not change. Under the hood, the workflow is still based on XMLReader.

What changes is the level of abstraction.

Instead of manually managing cursor flow and converting node fragments inline, the library lets me say:

stream through the XML;
select matching nodes;
receive structured PHP arrays for those nodes.

Here is the same scenario using FastXmlParser::extractHierarchy()
and XmlElement:

use SbWereWolf\XmlNavigator\Navigation\XmlElement;
use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$reader = new XMLReader();

if (! $reader->open('feed.xml')) {
    throw new RuntimeException('Cannot open XML file.');
}

$rows = [];

foreach (
    FastXmlParser::extractHierarchy(
        $reader,
        static fn (XMLReader $cursor): bool =>
            $cursor->nodeType === XMLReader::ELEMENT
            && $cursor->name === 'offer'
    ) as $offerData
) {
    $offer = new XmlElement($offerData);
    $name = $offer->pull('name')->current();
    $price = $offer->pull('price')->current();

    $rows[] = [
        'id' => $offer->get('id'),
        'available' => $offer->get('available') === 'true',
        'name' => $name?->value() ?? '',
        'price' => (float) ($price?->value() ?? 0),
        'currency' => $price?->get('currency') ?? '',
    ];
}

$reader->close();

var_export($rows);

The result is the same kind of application-level array:

array (
  0 =>
  array (
    'id' => '1001',
    'available' => true,
    'name' => 'Keyboard',
    'price' => 49.9,
    'currency' => 'USD',
  ),
  1 =>
  array (
    'id' => '1002',
    'available' => false,
    'name' => 'Mouse',
    'price' => 19.9,
    'currency' => 'USD',
  ),
)

That is the key comparison.

Both approaches are streaming-based. Both avoid loading the full XML document into memory. Both can solve the same extraction task.

The difference is where the complexity lives.

The practical difference

With raw XMLReader, the extraction loop carries several
responsibilities at once:

traversal;
node matching;
fragment parsing;
data mapping;
shape normalization.

With XmlExtractKit, traversal remains streaming-based, but extraction becomes more explicit and reusable.

That matters because most XML integration code is not judged only by whether it works today. It is judged by what happens when you need to:

add another field;
support optional nodes;
process another repeated element type;
reuse the same extraction pattern in a second project;
hand the code to someone else six months later.

In other words, the comparison is not just about performance. It is about where you want complexity to accumulate.

What raw XMLReader is still excellent for

It is worth being very clear here: this is not an argument against XMLReader.

XMLReader is the right foundation for large XML handling in PHP.

And there are cases where staying close to the metal is still the best option:

the task is small and one-off;
you need very custom cursor-level logic;
the extraction rules are extremely specific;
introducing another abstraction would not pay for itself.

When that is the case, use raw XMLReader and move on.

That is a completely reasonable engineering choice.

Where XmlExtractKit starts paying off

A focused extraction toolkit starts making sense when the job repeats.

That usually means one or more of these are true:

XML files are large enough that streaming is mandatory;
extraction is a recurring integration pattern;
the codebase needs arrays, not XML trees;
multiple projects solve similar feed or import tasks;
you want a stable intermediate representation of XML records;
you want the extraction code to read like the task, not like cursor choreography.

That is the use case I built sbwerewolf/xml-navigator for.

I did not want a general-purpose XML mega-toolkit. I wanted a practical way to keep the memory-safe streaming model while reducing how much extraction glue code I had to keep rewriting.

A more honest way to compare XML tools

One of the reasons XML discussions become unhelpful is that people compare tools that are not aimed at the same job.

A better comparison framework looks like this:

DOM / SimpleXML when the document is small and full-tree convenience matters;
raw XMLReader when the file is large and the task is custom enough that low-level control is worth it;
XmlExtractKit when the file is large, the task is extraction-focused, and you want structured arrays instead of repeated cursor glue.

That is much more useful than asking for a universal winner.

There is no universal winner.

There is only a better fit for the task in front of you.

So which one should you choose?

Here is my practical answer.

Choose raw XMLReader when:

you want maximal control;
the task is narrow;
the extraction code will probably never be reused;
a little extra boilerplate is acceptable.

Choose XmlExtractKit when:

you keep solving the same extraction problem repeatedly;
you want the XML stage to produce structured PHP arrays;
you want extraction code that is easier to read and maintain;
you want to stay streaming-first without hand-writing the same conversion patterns again and again.

Conclusion

For real XML extraction tasks in PHP, the main decision is usually not "which XML package is best?"

It is this:

Do I want to keep solving this at the raw XMLReader level, or do I want a reusable extraction-oriented layer on top of the same streaming model?

That is the honest comparison.

XMLReader is still the correct low-level foundation for large XML files.

But if your actual problem is repeated extraction of business records into plain PHP arrays, then XmlExtractKit (sbwerewolf/xml-navigator) is designed to make that workflow cleaner, more reusable, and easier to maintain.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

How to Parse Large XML Files in PHP Without Running Out of Memory

Nicholas Volkhin — Sun, 12 Apr 2026 20:01:05 +0000

XML is still everywhere: supplier feeds, marketplace catalogs, partner exports, legacy APIs, SOAP-ish payloads, ETL jobs. None of that is glamorous, but plenty of production systems still depend on it.

The real problem starts when the file is no longer small.

At that point, the question is not really "How do I parse XML in PHP?" It becomes:

How do I process a large XML document safely, extract only the records I care about, and keep the rest of my application working with normal PHP data structures?

That is a very different problem.

In many real-world integrations, you do not need the whole XML document in memory. You do not need to traverse every branch of the tree. You do not need a rich DOM-style model.

You usually need something much simpler:

scan the file efficiently;
find repeated business records such as product, offer, or item;
extract those records;
turn them into arrays;
pass them to the rest of your pipeline.

That is the approach I use in modern PHP projects, and it is the one I recommend for large XML workloads.

Why naive XML parsing stops working

For small files, the usual PHP XML tools are perfectly fine.

A typical first solution looks like this:

$xml = simplexml_load_file('feed.xml');

foreach ($xml->products->product as $product) {
    // process product
}

There is nothing wrong with that when the file is small and the document structure is simple.

The trouble is that this style of code implicitly treats the XML file as something you want to load and work with as a whole. For large feeds, that is often the wrong tradeoff.

If you only need repeated business records from a large XML file, materializing the entire document in memory is unnecessary work. It also makes your pipeline more fragile as feeds grow over time.

This is why large-XML handling should start with a different mental model:

Do not load the document. Stream through it and extract only what matters.

The real task is usually extraction, not XML manipulation

In practice, most XML processing jobs in application code look like this:

the file contains many repeated records;
you only need a subset of them;
you only need some fields from each record;
the result will end up in arrays, JSON, a database, or a queue.

That means the business task is usually not "work with XML as a document."

It is:

Find the repeated records I care about and turn them into application-friendly data.

That distinction matters because it leads directly to the right low-memory approach.

The memory-safe foundation: XMLReader

In PHP, the standard low-level tool for memory-safe XML traversal is XMLReader.

Instead of loading the entire document, it lets you move through the XML cursor-style, node by node.

That is exactly what you want when the file is large.

Here is a minimal baseline example:

$reader = new XMLReader();

if (! $reader->open('feed.xml')) {
    throw new RuntimeException('Cannot open XML file.');
}

while ($reader->read()) {
    if (
        $reader->nodeType === XMLReader::ELEMENT
        && $reader->name === 'product'
    ) {
        $nodeXml = $reader->readOuterXML();

        $product = simplexml_load_string($nodeXml);

        $data = [
            'id' => (string) $product->id,
            'name' => (string) $product->name,
            'price' => (float) $product->price,
            'available' => (string) $product->available,
        ];

        // process $data immediately
    }
}

$reader->close();

This is already much better than loading the full file up front.

It gives you the right execution model:

sequential reading;
low memory pressure;
immediate processing of extracted records.

If your XML task is simple and one-off, this may be enough.

But once you do this in more than one project, the weak points show up quickly.

Where raw XMLReader starts to hurt

XMLReader is powerful, but it is also low-level.

The moment your extraction task becomes slightly more realistic, you start accumulating glue code:

repeated node-selection logic;
conversion of XML fragments into arrays;
nested element handling;
attributes versus values;
optional nodes;
repeated fields like multiple <picture> tags;
serialization to JSON-friendly structures;
duplicated extraction code across projects.

At that point, memory is no longer the only concern.

Maintainability becomes the real cost.

This is the line I care about most in application code: not just "can I stream it," but "can I keep the extraction logic readable after the third similar integration?"

A more practical extraction-first approach

This is exactly why I built XmlExtractKit for PHP, published as sbwerewolf/xml-navigator.

The goal is not to replace XMLReader, but to keep its streaming model while moving application code closer to the actual business task.

Instead of managing the cursor manually and assembling records by hand, I want code that says:

open a large XML stream;
match the elements I care about;
get plain PHP arrays back.

Here is a streaming example using the library:

use SbWereWolf\XmlNavigator\Parsing\FastXmlParser;

require_once __DIR__ . '/vendor/autoload.php';

$uri = tempnam(sys_get_temp_dir(), 'xml-extract-kit-');
file_put_contents($uri, <<<'XML'
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
  <offer id="1001" available="true">
    <name>Keyboard</name>
    <price currency="USD">49.90</price>
  </offer>
  <service id="s-1">
    <name>Warranty</name>
  </service>
  <offer id="1002" available="false">
    <name>Mouse</name>
    <price currency="USD">19.90</price>
  </offer>
</catalog>
XML);

$reader = XMLReader::open($uri);

if ($reader === false) {
    throw new RuntimeException('Cannot open XML file.');
}

$offers = FastXmlParser::extractPrettyPrint(
    $reader,
    static fn (XMLReader $cursor): bool =>
        $cursor->nodeType === XMLReader::ELEMENT
        && $cursor->name === 'offer'
);

foreach ($offers as $offer) {
    echo json_encode(
        $offer,
        JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
    ) . PHP_EOL;
}

$reader->close();
unlink($uri);

The output is application-friendly:

{
  "offer": {
    "@attributes": {
      "id": "1001",
      "available": "true"
    },
    "name": "Keyboard",
    "price": {
      "@value": "49.90",
      "@attributes": {
        "currency": "USD"
      }
    }
  }
}

{
  "offer": {
    "@attributes": {
      "id": "1002",
      "available": "false"
    },
    "name": "Mouse",
    "price": {
      "@value": "19.90",
      "@attributes": {
        "currency": "USD"
      }
    }
  }
}

This is still a streaming workflow. The difference is that the code is now centered on the extraction task instead of low-level cursor management.

That becomes more valuable when the XML structure is nested, partially optional, or reused across multiple integrations.

Why plain arrays are often the right output

A lot of application code does not really want XML.

It wants data.

Once the relevant record has been extracted, the rest of the system usually prefers:

plain arrays;
normalized values;
JSON-ready structures;
data that can be validated, transformed, and persisted.

That is why I think "XML extraction" is a more useful framing than "XML handling."

Most business systems do not want to live inside an XML tree. They want to move past it as quickly as possible.

If the XML document is just a transport format, then the best workflow is usually:

XML stream -> selected nodes -> PHP arrays

That is the design center of my library.

When this approach makes sense

This style of XML processing works especially well when:

the XML file is large;
the document contains many repeated records;
you only need part of the document;
the extracted data should be processed immediately;
the rest of the application works with arrays, not DOM objects.

Typical examples include:

supplier and marketplace feeds;
product catalogs;
partner imports and exports;
ETL jobs;
queue payload preparation;
legacy integration endpoints that still speak XML.

When you probably do not need it

There are also cases where this is the wrong tool.

You probably do not need a streaming extraction approach when:

the XML is small;
loading the whole file is acceptable;
you need full-document manipulation;
your task is closer to DOM transformation than record extraction;
the XML structure is simple enough that a tiny one-off script is
enough.

That is important to say explicitly.

Not every XML task needs an extraction-first workflow. But the ones that do usually benefit from it immediately.

A useful rule of thumb

Here is the simplest practical rule I know:

if the XML is small and you need the whole document, convenience APIs are fine;
if the XML is large and you only need repeated records, stream it;
if you keep solving the same streaming extraction problem in multiple projects, stop writing the same glue code over and over.

That is the point where a focused library becomes worth it.

Conclusion

Large XML files are not primarily a parsing problem.

They are an extraction problem.

If you treat them like full in-memory documents, you often pay too much in memory and complexity. If you treat them like streams of repeated business records, the solution becomes safer, simpler, and much easier to fit into modern PHP pipelines.

XMLReader gives you the right low-level foundation for that model.

And if your real task is not "load XML," but "extract matching records and turn them into plain PHP arrays," then XmlExtractKit (sbwerewolf/xml-navigator) was built exactly for that workflow.

Try it

composer require sbwerewolf/xml-navigator

Explore the demo project

git clone https://github.com/SbWereWolf/xml-extract-kit-demo-repo.git
cd xml-extract-kit-demo-repo
composer install

Forem: Nicholas Volkhin

When to Use XmlExtractKit Instead of General XML Tools in PHP

First: what XmlExtractKit is actually for

Category 1: small XML, simple reads

Category 2: full-document manipulation

Category 3: large XML, but low-level control is enough

Category 4: large XML and repeated extraction tasks

Category 5: XML as XML versus XML as transport

Category 6: normalized traversal after conversion

A simple decision matrix

When XmlExtractKit is probably the better fit

When a general XML tool is probably the better fit

The practical mistake to avoid

Conclusion

Try it

Explore the demo project

Benchmark: XMLReader vs XmlExtractKit on a Real Extraction Scenario

What the benchmark should measure

The scenario: one realistic extraction task

What exactly is being compared

1. Raw XMLReader

2. XmlExtractKit (sbwerewolf/xml-navigator)

Why I am not publishing arbitrary numbers here

Step 1: generate a reproducible XML fixture

Step 2: the raw XMLReader baseline

Step 3: the XmlExtractKit implementation

Step 4: use a benchmark harness that measures the right things

What I would expect to see

Peak memory

Time to first record

Total runtime

Userland code size and complexity

What would make the benchmark unfair

My interpretation of this comparison

Conclusion

Try it

Explore the demo project

Processing Supplier and Marketplace XML Feeds in PHP

The real shape of feed-processing work

What makes feeds different from small XML documents

1. They are repetitive by nature

2. You rarely need everything

3. The output is almost never “more XML”

A representative feed example

The two stages that matter most

Stage 1: extraction

Stage 2: normalization

Why streaming is such a good fit for feeds

Why readable arrays help so much in feed work

The normalization step is where your business rules belong

Repeated tags, attributes, and optional fields are not edge cases

One feed is manageable. Ten feeds expose architecture problems

A useful split for real projects

Integration edge

Normalization layer

Application layer

When a full-document approach is still fine

Conclusion

Try it

Explore the demo project

Converting XML Feeds to Plain PHP Arrays in Modern PHP

Why arrays are usually the real target

A typical XML feed problem

The first decision: readable arrays or normalized hierarchy

Readable output: best for application code

When normalized output is the better choice

Arrays are only useful if they are easy to navigate

Why this matters in feed processing

What about large feeds?

A useful decision rule

One more practical point: XML should not leak everywhere

Conclusion

Try it

Explore the demo project

XMLReader vs XmlExtractKit for Real XML Extraction Tasks in PHP

The task

Option 1: raw XMLReader

What the raw XMLReader version costs you

Option 2: XmlExtractKit on top of XMLReader

The practical difference

1. Raw `XMLReader`

2. `XmlExtractKit` (`sbwerewolf/xml-navigator`)