Why should you avoid calling toString() repeatedly on large Axiom trees?

Each call to toString() triggers a full serialization of the element and, if the underlying tree isn't already completely built, forces the builder to finish materializing whatever remains unbuilt first - defeating the point of deferred building for that subtree.

Critically, the resulting string isn't cached anywhere on the element: calling toString() a second time re-serializes the entire subtree again from scratch, rather than reusing a previous result, so repeated calls (inside a logging statement in a loop, for instance) multiply the serialization cost linearly with the number of calls.

On a large tree, this compounds quickly - what looks like an innocuous debug log line evaluated once per iteration can end up doing far more parsing and string-building work than the rest of the surrounding logic combined, especially if it's sitting inside a hot path that runs per-message or per-request.

The practical fix is straightforward: serialize once, store the result in a local variable if you need it more than once, and be deliberate about where in a codebase full-tree toString() calls actually appear, particularly in logging statements that might not even be enabled at the current log level but whose arguments still get evaluated regardless.