Skip to content

Audit and fill math-kernel benchmark coverage #513

Description

@acgetchell

Context

#436 adapts the release-performance workflow from la-stack: shared command names, temp-worktree release comparisons, durable GitHub Release benchmark assets, and curated performance documentation.

That workflow intentionally keeps the default release-signal suite focused and stable. The broader math-kernel coverage review called out in #436 should be handled separately so we can decide which kernels belong in release-signal benchmarking, profiling, allocation checks, or targeted microbenchmarks without making the default release comparison too noisy.

Scope

Review Delaunay's math-intensive benchmark coverage and fill important gaps for release-relevant kernels. In particular, audit coverage for:

  • orientation predicates and exact fallback behavior;
  • barycentric simplex-intersection checks;
  • circumsphere / insphere predicate families;
  • simplex quality, volume, radius, and related geometry helpers;
  • ridge, Euler, manifold, and topology-validation work;
  • locate, hull traversal, and visible-facet queries;
  • simplex barycenter queries;
  • allocation hot paths only when output is stable enough for release-to-release comparison.

Deliverables

  • Decide which benchmarks belong in the release-signal suite versus broader profiling or targeted diagnostics.
  • Add focused Criterion benchmarks where meaningful coverage is missing.
  • Keep bench-latest curated: avoid adding noisy or expensive exploratory benchmarks by default.
  • Update benches/README.md with the benchmark taxonomy and any new commands or suites.
  • Run the matching benchmark compile/smoke validators, plus measured before/after evidence for any performance claims.

Acceptance Criteria

  • Existing benchmark coverage is mapped against the math-kernel list above.
  • Missing high-value kernels have focused benchmarks or an explicit rationale for deferral.
  • Release-signal membership is documented for each added or reviewed benchmark.
  • Benchmark docs explain which commands maintainers should use for release checks, regression checks, profiling, and kernel investigations.
  • New benchmark code preserves Delaunay's numerical, topological, and validation-layer invariants.

Metadata

Metadata

Assignees

No one assigned

    Labels

    performancePerformance related issuestestingIssues that come up in testing

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions