How does deferred building improve performance compared to DOM?

A conventional DOM parser must fully parse an entire document and materialize every node into an object before your code can touch any of it - even if the application only ever needs to inspect a small header near the top of a large payload.

Axiom's deferred builder, by contrast, only converts the portions of the document that are actually navigated into OM objects; content that's never visited stays as unconsumed StAX events (or unread bytes) rather than being needlessly turned into a full object graph.

This matters most for workloads like SOAP intermediaries or routing components, which frequently need to inspect only a message's headers - WS-Addressing information, for example - without caring about a potentially large body payload; on that kind of workload, Axiom can finish its work having built only a small fraction of the tree DOM would have been forced to build.

The tradeoff is that this benefit depends on access patterns: an application that eventually navigates the entire tree anyway - calling build() on the whole thing, or repeatedly re-serializing it - gets much less advantage, since it ends up materializing close to everything regardless.