How do you optimize XML processing performance using Axiom's caching option?

Axiom's builders expose a caching setting - commonly surfaced as isCache()/an equivalent constructor or configuration flag on the builder - that controls whether nodes pulled from the underlying parser are retained in the OM tree as they're built, or simply passed through for immediate use and then discarded.

With caching enabled (the default in most builder configurations), navigated nodes stay in the tree, so the structure can be traversed more than once, mutated, and re-serialized later - the normal mode of operation for most applications.

With caching disabled, the builder behaves closer to a pure single-pass streaming model: nodes are produced for immediate inspection but not retained, which reduces peak memory for workloads that only ever need to look at each part of the document exactly once, such as a validator or a simple transformation pipeline with no need to revisit earlier content.

Combining a non-caching pass with serializeAndConsume() for output, alongside a suitably high MTOM optimization threshold so large binaries stay out of base64 form, is a common pattern for squeezing extra throughput out of a purely pass-through service that neither needs to hold the full message in memory nor re-read any part of it twice.

The tradeoff to watch for is that disabling caching commits you to single-pass semantics - any code path that assumes it can navigate back to an already-visited node will simply find it gone, which can surface as confusing bugs if caching is turned off without auditing every downstream consumer of that tree first.