Is your feature request related to a problem? Please describe.
ev-node has granular OTLP spans across its codebase, but ev-reth currently only emits 3 span types:
- Storage trie (90.9% of total time)
- cache_for (7.3%)
- connection (1.8%)
This makes it difficult to identify bottlenecks in the execution layer during benchmarking.
Describe the solution you'd like
Add #[instrument] attributes to key functions in ev-reth to provide visibility into where time is spent. This will support ongoing benchmarking efforts and help identify optimization targets.
Describe alternatives you've considered
- Manual span creation: Insert
tracing::span! calls at specific points rather than using #[instrument] on entire functions. More control over what gets traced but more verbose and harder to maintain.
- Runtime-toggled profiling: Use a feature flag or runtime config to enable/disable detailed tracing. Avoids any overhead in production but adds complexity.
- External profiling tools: Use tools like
perf, flamegraph, or tokio-console instead of in-code instrumentation. Useful for one-off investigations but doesn't integrate with our existing OTLP pipeline.
Additional context
Is your feature request related to a problem? Please describe.
ev-node has granular OTLP spans across its codebase, but ev-reth currently only emits 3 span types:
This makes it difficult to identify bottlenecks in the execution layer during benchmarking.
Describe the solution you'd like
Add
#[instrument]attributes to key functions in ev-reth to provide visibility into where time is spent. This will support ongoing benchmarking efforts and help identify optimization targets.Describe alternatives you've considered
tracing::span!calls at specific points rather than using#[instrument]on entire functions. More control over what gets traced but more verbose and harder to maintain.perf,flamegraph, ortokio-consoleinstead of in-code instrumentation. Useful for one-off investigations but doesn't integrate with our existing OTLP pipeline.Additional context