How does Axiom achieve memory efficiency for large XML documents?

Axiom combines several mechanisms, rather than a single trick, to keep memory usage down on large documents.

• Deferred building - unvisited parts of the tree are never converted into objects at all, so an application that only inspects a header on a large payload avoids materializing the rest.
• serializeAndConsume() - for one-shot output, streaming events directly from the source to the destination avoids retaining a fully-built tree in memory at all.
• MTOM/XOP - binary content is kept as raw bytes referenced via a DataHandler rather than inflated into base64 text (which costs roughly a third more space) inline in the XML.
• Selective build() usage - calling build() only on the specific subtrees that genuinely need full, repeated navigation, rather than reflexively building the whole document.

None of these are free of tradeoffs: serializeAndConsume() sacrifices the ability to reuse the tree afterward, and skipping build() means later code must still be written defensively around the possibility that navigation triggers further parsing.

The practical upshot for interview purposes is that Axiom's efficiency isn't magic - it comes from deliberately not doing work (parsing, encoding) that a given access pattern doesn't actually require, which is also why Axiom's advantage shrinks for access patterns that end up touching the whole document anyway.