fix(transpile): #6664 serialize XMIR into one string in classes.xsl

[yegor256]

Closes #6664.

classes.xsl writes the XMIR of each top-level object into <xmir>, as the text to-java.xsl turns into the Javadoc of the generated class. The serialize template spelled that text out piece by piece — one instruction per indent, per angle bracket, per name and five per attribute. jcabi-xml runs every stylesheet DOM to DOM (DOMSource → DOMResult), so each piece became a separate DOM text node: a single <xmir> for string/printf.eo (~1.6k elements, ~8.3k attributes) held roughly 50k of them. Building them, and then reading them back through a DOM that has to merge adjacent text nodes to answer text(), cost far more than the concatenation itself — hence XSL 'classes' took 4s (over 500ms) from xsline's StFast on a single XMIR.

It is now an xsl:function returning one xs:string, written with one xsl:value-of, so <xmir> holds exactly one text node.

Numbers

Saxon-HE 13.0, all 170 sources of eo-runtime/src/main/eo parsed with EoSyntax and put through set-locators.xsl + set-original-names.xsl first, best of two warm runs, single-threaded:

	classes.xsl alone	whole transpile train (9 XSLs)	worst file, train (string/printf.eo)
before	21.5s	56.9s	8.0s
after	1.0s	34.4s	4.0s

21x for the pass, 1.7x for the train. The train gains more than the pass saves, because the eight downstream stylesheets no longer walk those adjacent text nodes either. For reference, replacing the serializer with an empty <xmir/> altogether takes the pass to 0.14s, so what is left is close to the floor.

Why nested concat and not a joined sequence

Two other shapes were measured on the 21 largest sources (baseline 15.2s there):

shape	time
function returning xs:string*, one string-join at the end	2.1s
same, but each attribute as its own sequence item	4.8s
function returning xs:string, recursive call inside concat (this PR)	0.53s

Nesting the recursive call copies a subtree's string once per level of depth above it, which at the depth of a real XMIR is far cheaper than Saxon's per-item bookkeeping. The rejected shapes are noted in the comment on the function so the next reader does not re-try them.

Correctness

• Output is byte-identical for all 170 eo-runtime sources — both of this pass alone, and of the full nine-stylesheet train, i.e. of the generated Java.
• MjTranspileTest (52 transpile packs) and FingerprintTest: 57 tests, all green.
• xcop clean on the changed file.
• The pass is fingerprinted into the transpile cache key via Transpilation.XSLS, so existing caches invalidate on their own.

Also in this diff

The class-matching pattern loses a redundant eo:atom call and a count(...) > 0:

-match="object/o[not(eo:atom(.)) or (eo:atom(.) and count(./o[eo:test-attr(.)])>0)]"
+match="object/o[not(eo:atom(.)) or exists(o[eo:test-attr(.)])]"

not(A) or (A and B) is not(A) or B. Not measurable next to the serializer, but it is the same question asked once instead of twice.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Improves transpilation performance by changing how classes.xsl serializes per-object XMIR into the generated <xmir> text used downstream for JavaDoc generation, ensuring the result is produced as a single DOM text node instead of tens of thousands of adjacent nodes.

Changes:

• Replaces the recursive serialize named template with an eo:serialize() xsl:function that returns a single xs:string, emitted via one xsl:value-of.
• Simplifies the class-selection match predicate by removing redundant eo:atom(.) work and using exists(...) instead of count(...) > 0.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[yegor256]

Keeping it, since the convention it appeals to isn't the one in this codebase: _funcs.xsl — the library this stylesheet imports — carries ten inline comments inside function bodies (<!-- 2-byte sequence: 110xxxxx 10xxxxxx -->, <!-- 55296 = 0xD800 --> and so on), all of them annotating a single line the way this one does.

The line above $void explains what the variable means — that an object with neither data nor children is written as a self-closing tag — while the doc comment above the function is about why the function has this shape at all (DOM text nodes, and the two slower shapes that were measured and rejected). Folding a one-line note about output format into that paragraph would bury it, and it belongs next to the variable it names.

---

Generated by Claude Code

[github-actions]

🚀 Performance Analysis

All benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information.

Click to see the detailed report

Test	Base Score	PR Score	Change	% Change	Unit	Mode
benchmarks.XslBench.manySheetsOnLargeXmir	816.672	836.829	20.156	2.47%	ms/op	Average Time

⚠️ Performance loss: benchmarks.XslBench.manySheetsOnLargeXmir is slower by 20.156 ms/op (2.47%)

[0crat]

@yegor256 Thanks for the contribution! You've earned +8 points for this: +16 as a basis; -8 for the lack of code review. Please, keep them coming. Your running score is +2874; don't forget to check your Zerocracy account too).