Skip to content

[Benchmark]: Measure interception and diagnostics overhead #58

Description

@rian-be

Summary

Benchmark the overhead introduced by interception and diagnostics in the core runtime.

Goal

Measure how much cost the core mutation pipeline adds when interception, audit/history capture, and logging are enabled so that changes in these layers can be tracked over time.

Problem

The core runtime includes several extension and observability paths that can affect execution cost: interceptors, audit/history capture, and logging. Those paths are useful, but they also add overhead that should remain visible as the runtime evolves.

Without benchmark dedicated to interception and diagnostics, it is hard to tell whether change slows down the execution pipeline itself or only the surrounding observability layers.

Scope

  • Benchmark interceptor overhead in the core mutation pipeline
  • Benchmark audit, history, and logger path overhead
  • Measure the combined impact on the execution pipeline when diagnostics are enabled
  • Keep the benchmark focused on core runtime observability paths
  • Reuse existing benchmark and diagnostics helpers where they already exist
  • Make the benchmark scenarios explicit enough to compare enabled and disabled paths over time

Design Expectations

  • Observability related overhead should be measured separately from mutation throughput.
  • The benchmark should make it clear which diagnostics path is being exercised.
  • Interception and logging should be benchmarked with realistic runtime flow rather than isolated toy loops.
  • Helper code should stay local to the benchmark project.
  • Scenario names should be explicit about what is being measured.

Suggested Measurements

  • execution without interceptors versus with interceptors
  • execution with audit/history logging enabled
  • execution with combined interception and diagnostics

Acceptance Criteria

  • Interceptor overhead is benchmarked in the core runtime
  • Audit/history/logger overhead is benchmarked as separate concern
  • The execution pipeline impact of observability is visible in benchmark results
  • The benchmark remains centered on the core runtime and not provider specific behavior

Non-Goals

  • This issue does not change logging or interception semantics
  • This issue does not add governance specific diagnostics benchmarks
  • This issue does not optimize observability code prematurely
  • This issue does not change runtime behavior

Notes

This issue is child of the benchmark umbrella #55.

Metadata

Metadata

Assignees

No one assigned

    Labels

    benchmarkBenchmark coverage and performance measurement changes

    Type

    No fields configured for Task.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions