Xpact-core: past the performance phase, now the correctness phase — still besting eXpat ×1.38

[Finnian Reilly]

Xpact-core: past  the performance phase, now the correctness phase — still besting eXpat ×1.38

This report presents new benchmark results for Xpact-core, a pure-Eiffel XML parser porting the behaviour of the widely-used C library eXpat (libexpat). It accompanies the paper Finding a Billion-User Project for Eiffel: How DbC Catches Security Flaws Rust Misses, where the motivation and architecture of Xpact-core are described in detail.

Making it fast was the easy part

Getting Xpact to run quickly turned out to be relatively straightforward. The hard part was making it correct — matching eXpat's output exactly across every edge case: predefined entity resolution, partial-token buffer boundaries, CDATA section handling, namespace attribute semantics, and character-reference encoding. A mismatch in any one of these produces a different CRC-32 value from the two parsers, which is immediately detectable.

A dual-purpose correctness and benchmarking tool

To verify correctness and measure performance in the same run, I had Claude write a C program — xml_crc_32.c — that serves two purposes:

1. It computes a CRC-32/ISO-HDLC hash over one of five parse-event data types (selectable on the command line), producing a single value that can be compared directly against Xpact's output.
2. It counts complete parse passes in a fixed time window, giving a throughput figure for benchmarking.

The five data types are text content, CDATA sections, comments, start-tag names, and attribute values. The Eiffel counterpart is CRC_32_GENERATOR. When both programs produce identical CRC-32 values for a given file and data type, the parsers are in agreement for that combination.

Earlier in the project I used a simpler program — xml_tag_counter.c — which generates a table of tag-name occurrence frequencies. Its Eiffel counterpart is TAG_COUNTER. This confirmed basic parse-tree correctness but cannot detect errors in text content or attribute values.

Benchmark sessions are driven by two scripts — benchmark_Xpact_crc_32.sh and benchmark_Xpact_tag_count.sh — which run both parsers against each test file and append results to log files, allowing performance regressions to be tracked over time.

Read the full report here: https://eiffel-loop.com/article/Xpact-benchmark-report.html

-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

[Liberty Lover]

So, I put Claude.code.ai into what I have taken to calling an "Adversarial Debate Cycle" where it does a GATHER of evidence, DEBATE team (red, blue, green, gold), and then ADJUDICATION cycles. These are handled (in order) by Sonnet, Opus, and then Fable. The debate is currently in-progress.

Previously, I have had Claude not only explore the project space, developing specs from existing systems, but to suggest ways to improve what is already there and also expand the capabilities of what is already there. This is a part of the debate-cycle it is presently in above.

I'm delighted to see AI applied this way. It turns out to be an outstanding match for Eiffel — and it's no surprise that the pairing is surfacing flaws the Rust model misses. The perennial blind spot for most engineers is Design by Contract and the tools waiting beyond it: AutoTest, AutoProof. Perhaps AI is what finally pushes those tools to the forefront of engineering minds — and helps us take the last steps toward mathematically proven systems.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/eb127f4f-50cf-45b5-8959-5a78eff2ec40%40eiffel-loop.com.

[Liberty Lover]

VERDICT is in!


In a nutshell ...

What I recommend instead (the constructive path)

Since the verdict is No, I'm not proceeding to deep specs for a parser fork — that was your conditional, and the evidence doesn't clear the bar. But the debate legitimized a smaller, genuinely special project that no competitor is doing and that costs a fraction of a fork:

1. Contribute the entity-expansion class invariant to Xpact-core upstream — invariant total_expanded <= input_size * Max_amplification_factor plus a recursion-depth precondition. This is the one thing that's truly novel (a structural fix for a bug class the whole industry patches ad-hoc), and it lands where the billion-user distribution actually is.
2. If and only if a consumer ever demands streaming or real namespaces, rebuild simple_xml's DOM facade on a pinned, vendored Xpact-core backend — shedding Gobo without owning a new engine. Defer until a real consumer asks.
3. Leave ECF parsing alone — the simple_graphify hand-scanner is the right-sized tool for sub-15 KB config files.