tests: add performance tests #36

original idea

• currently, the library is utterly slow. since it uses lark under the hood, what the parser generator is slow, and the generated parser is slow, too.
  this might change in the future.
• to see if a potential change is actually any perf improvement, we need tests that report how much resources(time, memory, etc...) they use
• tests shall go into the usual tests folder, but be in an own tests file.
• the perf shall test all provided parsers, no only the main iri one ...
  tests should work with not-to0-much randomized data (zero at best), so that a certain reproducibility is possible, for comparison reasons.
  we test sfor average cases - not edge cases ....

tests: add performance tests

Context

The library is currently quite slow. Since it uses lark under the hood, performance is affected by both:

1. parser generation/build time, and
2. runtime parse performance of the generated parser.

This may improve in the future. To verify whether changes are real improvements, we need reproducible performance tests that report resource usage.

Goal

Add a dedicated performance test suite in tests/ (separate file/module from functional tests) that benchmarks all provided parsers, not only the main iri parser.

The suite should focus on average-case inputs (not edge/pathological cases) and be as reproducible as possible (ideally zero randomization).

1) Test location and structure

• Add perf tests under the normal tests folder in a dedicated file, e.g.:
  • tests/test_perf.py (or similar dedicated perf module)
• Mark them separately (e.g. @pytest.mark.perf) so they can be run independently from normal tests.

2) Benchmarked parser coverage

Benchmark all parser entry points provided by the library.
In the implementation, explicitly list which parser APIs are covered so scope is unambiguous.

3) Metrics to collect

Collect and report at least:

• Parser build/init time (where applicable)
• Parse runtime (throughput or latency; e.g. ops/s or ms/op)
• Peak memory usage during parsing (and allocations if practical)

Build/init and parse runtime must be measured separately.

4) Benchmark harness

Use a stable benchmark approach (e.g. pytest + pytest-benchmark, or equivalent) with fixed settings for:

• warmup
• iterations / rounds
• repeat count

Export machine-readable results (JSON) for comparison over time.

5) Reproducibility

• Prefer deterministic, fixed input corpora in-repo (small / medium / large average-case datasets).
• If any random generation is used, use a fixed seed and document it.
• Document runtime environment in output:
  • Python version
  • OS/platform
  • relevant dependency versions (especially lark)

6) Baseline comparison output

Test output should include a comparison table per parser and dataset, with at least:

• parser name
• dataset name/size
• runtime metric (ops/s or ms/op)
• peak memory
• delta vs baseline (if baseline available)

7) CI strategy

• PR CI: run a lightweight perf smoke subset (report-only)
• Scheduled/manual CI: run full perf suite and upload JSON/results as artifacts

8) Regression policy

Start as report-only (no hard fail) unless/until noise is characterized.
Optional follow-up: enforce thresholds (e.g. fail if >10% regression vs baseline).

Non-goals

• No edge-case/pathological benchmarking in this ticket.
• No broad optimization refactors in this ticket; this is about adding measurement infrastructure.

Acceptance Criteria

• Dedicated perf test module exists under tests/
• Perf tests are separately runnable (e.g. marker-based)
• All public parser entry points are benchmarked
• Build/init time and parse runtime are reported separately
• Peak memory is measured and reported
• Results can be exported in machine-readable format (JSON)
• Inputs are reproducible (fixed corpus and/or fixed seed)
• CI runs perf smoke on PRs and full perf on schedule/manual trigger
• Output includes parser/dataset metrics and baseline deltas (where available)
• CI runs perf smoke on PRs and full perf NOT on build/deploy/release trigger