> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/a16z/jolt/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance Optimizations Overview

> Key optimizations in Jolt zkVM that achieve industry-leading prover performance

Jolt zkVM achieves exceptional proving performance through a comprehensive suite of optimizations across multiple layers of the proving system. These optimizations target the most compute-intensive operations: sumcheck protocols, polynomial evaluations, and commitment scheme operations.

## Performance-Critical Components

The prover hot path is dominated by:

* **Sumcheck inner loop**: Polynomial binding, evaluations, and EQ polynomial operations
* **Commitment operations**: Batched polynomial openings and Dory commitment computations
* **Memory operations**: Polynomial coefficient storage and manipulation

## Core Optimizations

### Protocol-Level Optimizations

<CardGroup cols={2}>
  <Card title="Batched Sumcheck" icon="layer-group" href="/architecture/optimizations/batched-sumcheck">
    Reduces verifier cost and proof size by batching parallel sumcheck instances
  </Card>

  <Card title="Batched Openings" icon="folder-open" href="/architecture/optimizations/batched-openings">
    Amortizes polynomial opening proof costs across multiple polynomials
  </Card>
</CardGroup>

### Data Structure Optimizations

<CardGroup cols={2}>
  <Card title="Small Value Polynomials" icon="compress" href="/architecture/optimizations/small-value">
    Compact representation for polynomials with small scalar coefficients
  </Card>

  <Card title="EQ Polynomial Optimizations" icon="equals" href="/architecture/optimizations/eq-optimizations">
    Specialized algorithms for equality polynomial evaluations
  </Card>
</CardGroup>

### Advanced Techniques

<CardGroup cols={2}>
  <Card title="Cryptographic Inlines" icon="microchip" href="/architecture/optimizations/inlines">
    Replace expensive RISC-V execution with constraint-native primitives
  </Card>

  <Card title="Torus Compression" icon="file-zipper" href="/architecture/optimizations/compression">
    Proof size reduction through torus-based compression
  </Card>
</CardGroup>

## Performance Impact

These optimizations work together to achieve:

* **10-100x prover speedup** from CompactPolynomial vs. full field elements
* **Linear complexity reduction** through batched sumcheck protocols
* **2-5x throughput improvement** from cryptographic inlines
* **3x proof size reduction** from torus compression (estimated)

## Design Principles

### 1. Hot Path Focus

Optimizations target operations executed thousands of times per proof:

* Polynomial binding operations in sumcheck rounds
* EQ polynomial evaluations across multiple instances
* Field arithmetic in inner loops

### 2. Memory Efficiency

* CompactPolynomial: Store u8/u16/u32 coefficients instead of 32-byte field elements
* SharedRaPolynomials: Share EQ tables across multiple polynomials
* Lazy materialization: Defer field element conversion until binding

### 3. Parallelization

All critical paths support parallel execution:

* Parallel polynomial binding for large coefficients
* Parallel EQ table computation
* Parallel sumcheck instance evaluation

### 4. Zero-Copy Operations

Minimize allocations and clones:

* In-place polynomial updates where possible
* Pre-allocated buffers with known sizes
* Unsafe allocation for zero-initialization

## Implementation Guidelines

<Warning>
  Performance is **CRITICAL** in jolt-core. Profile before optimizing, and benchmark any changes to `poly/` code — small regressions multiply across thousands of sumcheck rounds.
</Warning>

### Profiling Tools

```bash theme={null}
# Execution trace (viewable in Perfetto)
cargo run --release -p jolt-core profile --name sha3 --format chrome

# Memory profiling (outputs SVG flamegraphs)
RUST_LOG=debug cargo run --release --features allocative -p jolt-core profile --name sha3 --format chrome
```

### Benchmarking Changes

Small regressions in polynomial operations compound:

* A 1% slowdown in `bind()` affects every sumcheck round
* Memory allocations in inner loops are **strictly prohibited**
* Use `#[inline]` judiciously on hot paths

## Next Steps

Explore each optimization in detail to understand implementation techniques and performance impact:

1. Start with [Batched Sumcheck](/architecture/optimizations/batched-sumcheck) to understand protocol-level batching
2. Learn about [CompactPolynomial](/architecture/optimizations/small-value) for memory-efficient polynomial storage
3. Discover [Cryptographic Inlines](/architecture/optimizations/inlines) for domain-specific acceleration
