performance-investigation

name	performance-investigation
description	Profile and identify performance bottlenecks in Constantine cryptographic code using metering and benchmarking tools. Use when optimizing cryptographic algorithms, analyzing hotspots, or comparing implementations against reference benchmarks.
license	MIT
metadata	{"audience":"developers","language":"nim","domain":"cryptography"}

What I do

Help identify and analyze performance bottlenecks in Constantine cryptographic implementations through:

• Metering: Count operations (field mul, add, EC ops, scalar muls) with -d:CTT_METER flag
• Benchmarking: Measure ops/s, ns/op, CPU cycles with -d:danger flag
• Profiling: Create small test binaries for detailed analysis with perf or similar tools
• Comparison: Compare implementations against reference (e.g., C-kzg-4844)

When to use me

Use this skill when:

1. Implementation is slower than expected (e.g., 50% slower than reference)
2. Need to identify hotspots in cryptographic algorithms (FK20, FFT, MSM, pairings)
3. Optimizing critical paths in PeerDAS (EIP-7594) or KZG (EIP-4844) code
4. Validating algorithmic complexity (e.g., O(n log n) vs O(n²))
5. Comparing optimization strategies (fixed-base vs variable-base MSM)

How to investigate performance

Step 1: Enable Metering

Add {.meter.} pragma to suspect procedures:

import constantine/platforms/abstractions  # Re-exports metering/tracer

proc hotspotFunction*(...) {.meter.} =
  # This will be tracked when compiled with -d:CTT_METER

Step 2: Create Test Binary

Create a minimal test file in metering/ or build/:

# metering/m_your_test.nim
import
  constantine/platforms/metering/[reports, tracer],
  # ... your imports

proc main() =
  resetMetering()
  yourFunction()
  reportCli(Metrics, "UseAssembly")

when isMainModule:
  main()

Step 3: Compile with Metering

nim c -r --hints:off --warnings:off --verbosity:0 \
  -d:danger -d:CTT_METER \
  --outdir:build \
  metering/m_your_test.nim

Step 4: Analyze Output

Metering output shows:

• # of Calls: How many times each proc was called
• Throughput (ops/s): Operations per second
• Time (µs): Total and average time per call
• CPU cycles: Approximate cycle count (indicative only)

Look for:

• High call counts × high avg time = primary bottleneck
• EC operations (scalarMul, multiScalarMul) are typically 100-1000× slower than field ops
• Variable-base MSM vs fixed-base MSM can differ by 5-10×

Step 5: For Detailed Profiling

Compile a small binary for perf:

nim c -d:danger --debugger:native \
  --outdir:build \
  metering/m_your_test.nim

# Then use perf, vtune, or similar
perf record -- ./build/m_your_test
perf report

Key Patterns in Constantine

Metering Infrastructure

• constantine/platforms/metering/tracer.nim: Defines {.meter.} macro
• constantine/platforms/metering/reports.nim: CLI reporting
• constantine/platforms/abstractions.nim: Re-exports metering primitives
• Flag: -d:CTT_METER enables metering (off by default)

Common Bottlenecks

1. Scalar Multiplication (scalarMul_vartime)

2. Multi-Scalar Multiplication (multiScalarMul_vartime)

   • Look for Pippenger vs fixed-base optimization opportunities

3. FFT Operations (fft_nr, ec_fft_nr)

4. Field Operations (prod, square, inv)

   • inv and inv_vartime are much slower than mul (~100×)
   • Batch inversion can help

Notes

• Metering overhead: Metering adds ~10-20% overhead; use for relative comparison, not absolute timing
• Cycle counts: CPU cycle measurements are approximate (affected by turbo boost, throttling)
• Compiler effects: GCC vs Clang can differ significantly on bigint arithmetic
• Assembly: Constantine's compile-time assembler improves performance; check UseASM_X86_64 flag