681 lines
19 KiB
Markdown
681 lines
19 KiB
Markdown
# Compute Unit Optimization Guide
|
||
|
||
This guide provides comprehensive techniques for optimizing compute unit (CU) usage in Solana native Rust programs, compiled from official Solana documentation, community repositories, and expert resources.
|
||
|
||
## Understanding Compute Units
|
||
|
||
### Compute Limits
|
||
|
||
Solana enforces strict compute budgets to ensure network performance:
|
||
|
||
- **Max CU per block**: 60 million CU
|
||
- **Max CU per account per block**: 12 million CU
|
||
- **Max CU per transaction**: 1.4 million CU
|
||
- **Default soft cap per transaction**: 200,000 CU
|
||
|
||
Programs can request higher compute budgets using the Compute Budget program, up to the 1.4M hard limit.
|
||
|
||
### Transaction Fees
|
||
|
||
Transaction fees consist of two components:
|
||
|
||
1. **Base fee**: 5,000 lamports per signature (fixed, independent of CU usage)
|
||
2. **Priority fee**: Optional additional fee to prioritize transaction inclusion
|
||
|
||
Priority fees are calculated as:
|
||
```
|
||
priority_fee = microLamports_per_CU × requested_compute_units
|
||
```
|
||
|
||
### Why Optimize CU Usage?
|
||
|
||
Even though current fees don't scale with CU usage within the budget, optimization matters:
|
||
|
||
1. **Block inclusion probability**: Smaller transactions are more likely to fit in congested blocks
|
||
2. **Composability**: When your program is called via CPI, it shares the caller's CU budget
|
||
3. **Efficient resource usage**: Better utilization of limited block space
|
||
4. **Future-proofing**: Fee structures may change to account for actual CU consumption
|
||
5. **User experience**: Faster transaction execution and lower rejection rates
|
||
|
||
## Common Optimization Techniques
|
||
|
||
### 1. Logging Optimization (Highest Impact)
|
||
|
||
Logging is one of the most expensive operations in Solana programs.
|
||
|
||
**Anti-patterns:**
|
||
|
||
```rust
|
||
// EXPENSIVE: 11,962 CU
|
||
// Base58 encoding + string concatenation
|
||
msg!("A string {0}", ctx.accounts.counter.to_account_info().key());
|
||
|
||
// EXPENSIVE: 357 CU
|
||
// String concatenation
|
||
msg!("A string {0}", "5w6z5PWvtkCd4PaAV7avxE6Fy5brhZsFdbRLMt8UefRQ");
|
||
```
|
||
|
||
**Best practices:**
|
||
|
||
```rust
|
||
// EFFICIENT: 262 CU
|
||
// Use .key().log() directly
|
||
ctx.accounts.counter.to_account_info().key().log();
|
||
|
||
// BETTER: 206 CU
|
||
// Store in variable first
|
||
let pubkey = ctx.accounts.counter.to_account_info().key();
|
||
pubkey.log();
|
||
|
||
// CHEAPEST: 204 CU
|
||
// Simple string logging
|
||
msg!("Compute units");
|
||
```
|
||
|
||
**Recommendation**: Avoid logging in production unless absolutely necessary for debugging. Remove or conditionally compile logging for mainnet deployments.
|
||
|
||
### 2. Data Type Optimization
|
||
|
||
Smaller data types consume fewer compute units.
|
||
|
||
**Comparison:**
|
||
|
||
```rust
|
||
// 618 CU - u64
|
||
let mut a: Vec<u64> = Vec::new();
|
||
for _ in 0..6 {
|
||
a.push(1);
|
||
}
|
||
|
||
// 600 CU - i32 (default integer type)
|
||
let mut a = Vec::new();
|
||
for _ in 0..6 {
|
||
a.push(1);
|
||
}
|
||
|
||
// 459 CU - u8 (best for small values)
|
||
let mut a: Vec<u8> = Vec::new();
|
||
for _ in 0..6 {
|
||
a.push(1);
|
||
}
|
||
```
|
||
|
||
**Initialization vs pushing:**
|
||
|
||
```rust
|
||
// 357 CU - Pushing elements one by one
|
||
let mut a: Vec<u64> = Vec::new();
|
||
for _ in 0..6 {
|
||
a.push(1);
|
||
}
|
||
|
||
// 125 CU - Direct initialization (65% savings!)
|
||
let _a: Vec<u64> = vec![1, 1, 1, 1, 1, 1];
|
||
```
|
||
|
||
**Best practice**: Use the smallest data type that fits your requirements (u8 > u16 > u32 > u64), and prefer `vec![]` initialization over repeated `push()` calls.
|
||
|
||
### 3. Serialization: Zero-Copy vs Borsh
|
||
|
||
Zero-copy deserialization can provide massive CU savings for account operations.
|
||
|
||
**Standard Borsh serialization:**
|
||
|
||
```rust
|
||
// 6,302 CU - Standard account initialization
|
||
pub fn initialize(_ctx: Context<InitializeCounter>) -> Result<()> {
|
||
Ok(())
|
||
}
|
||
|
||
// 2,600 CU total for increment (including serialization overhead)
|
||
pub fn increment(ctx: Context<Increment>) -> Result<()> {
|
||
let counter = &mut ctx.accounts.counter;
|
||
counter.count = counter.count.checked_add(1).unwrap(); // 108 CU for operation
|
||
Ok(())
|
||
}
|
||
```
|
||
|
||
**Zero-copy optimization:**
|
||
|
||
```rust
|
||
// 5,020 CU - Zero-copy initialization (20% savings)
|
||
pub fn initialize_zero_copy(_ctx: Context<InitializeCounterZeroCopy>) -> Result<()> {
|
||
Ok(())
|
||
}
|
||
|
||
// 1,254 CU total for increment (52% savings!)
|
||
pub fn increment_zero_copy(ctx: Context<IncrementZeroCopy>) -> Result<()> {
|
||
let counter = &mut ctx.accounts.counter_zero_copy.load_mut()?;
|
||
counter.count = counter.count.checked_add(1).unwrap(); // 151 CU for operation
|
||
Ok(())
|
||
}
|
||
```
|
||
|
||
**Zero-copy account definition:**
|
||
|
||
```rust
|
||
#[account(zero_copy)]
|
||
#[repr(C)]
|
||
#[derive(InitSpace)]
|
||
pub struct CounterZeroCopy {
|
||
count: u64,
|
||
authority: Pubkey,
|
||
big_struct: BigStruct, // Can include large structs without stack overflow
|
||
}
|
||
```
|
||
|
||
**Benefits of zero-copy:**
|
||
- 50%+ CU savings on serialization/deserialization
|
||
- Avoids stack frame violations with large account structures
|
||
- Direct memory access without intermediate copying
|
||
- Particularly valuable for frequently updated accounts
|
||
|
||
**Trade-off**: Slightly more complex API (`load()`, `load_mut()`) and requires `#[repr(C)]` for memory layout guarantees.
|
||
|
||
### 4. Program Derived Addresses (PDAs)
|
||
|
||
PDA operations vary significantly in cost depending on the method used.
|
||
|
||
**Finding PDAs:**
|
||
|
||
```rust
|
||
// EXPENSIVE: 12,136 CU
|
||
// Iterates through nonces to find valid bump seed
|
||
let (pda, bump) = Pubkey::find_program_address(&[b"counter"], ctx.program_id);
|
||
|
||
// EFFICIENT: 1,651 CU (87% savings!)
|
||
// Uses known bump seed directly
|
||
let pda = Pubkey::create_program_address(&[b"counter", &[248_u8]], &program_id).unwrap();
|
||
```
|
||
|
||
**Optimization strategy:**
|
||
|
||
1. Use `find_program_address()` **once** during account initialization
|
||
2. Save the bump seed in the account data
|
||
3. Use `create_program_address()` with the saved bump for all subsequent operations
|
||
|
||
**Anchor implementation:**
|
||
|
||
```rust
|
||
// Account structure - save the bump
|
||
#[account]
|
||
pub struct CounterData {
|
||
pub count: u64,
|
||
pub bump: u8, // Store the bump seed here
|
||
}
|
||
|
||
// EXPENSIVE: 12,136 CU - Without saved bump
|
||
#[account(
|
||
seeds = [b"counter"],
|
||
bump // Anchor finds it every time
|
||
)]
|
||
pub counter_checked: Account<'info, CounterData>,
|
||
|
||
// EFFICIENT: 1,600 CU - With saved bump (87% savings!)
|
||
#[account(
|
||
seeds = [b"counter"],
|
||
bump = counter_checked.bump // Use the saved bump
|
||
)]
|
||
pub counter_checked: Account<'info, CounterData>,
|
||
```
|
||
|
||
### 5. Cross-Program Invocations (CPIs)
|
||
|
||
CPIs add significant overhead compared to direct operations.
|
||
|
||
**CPI to System Program:**
|
||
|
||
```rust
|
||
// 2,215 CU - CPI for SOL transfer
|
||
let cpi_context = CpiContext::new(
|
||
ctx.accounts.system_program.to_account_info(),
|
||
system_program::Transfer {
|
||
from: ctx.accounts.payer.to_account_info().clone(),
|
||
to: ctx.accounts.counter.to_account_info().clone(),
|
||
},
|
||
);
|
||
system_program::transfer(cpi_context, 1_000_000)?;
|
||
```
|
||
|
||
**Direct lamport manipulation:**
|
||
|
||
```rust
|
||
// 251 CU - Direct operation (90% savings!)
|
||
let counter_account_info = ctx.accounts.counter.to_account_info();
|
||
let mut counter_lamports = counter_account_info.try_borrow_mut_lamports()?;
|
||
**counter_lamports += 1_000_000;
|
||
|
||
let payer_account_info = ctx.accounts.payer.to_account_info();
|
||
let mut payer_lamports = payer_account_info.try_borrow_mut_lamports()?;
|
||
**payer_lamports -= 1_000_000;
|
||
```
|
||
|
||
**Important caveats:**
|
||
|
||
1. **Error handling overhead**: Error paths add ~1,199 CU if triggered
|
||
2. **Safety**: Direct manipulation bypasses safety checks in the System Program
|
||
3. **Ownership**: Only safe when you control both accounts
|
||
4. **Rent exemption**: You're responsible for maintaining rent exemption
|
||
|
||
**Best practice**: Use CPIs for safety and correctness by default. Only optimize to direct manipulation when:
|
||
- You have tight CU constraints
|
||
- You fully understand the safety implications
|
||
- Both accounts are controlled by your program
|
||
|
||
### 6. Pass by Reference vs Clone
|
||
|
||
Solana's bump allocator doesn't free memory, making unnecessary cloning particularly problematic.
|
||
|
||
**Comparison:**
|
||
|
||
```rust
|
||
let balances = vec![10_u64; 100];
|
||
|
||
// EFFICIENT: 47,683 CU - Pass by reference
|
||
fn sum_by_reference(data: &Vec<u64>) -> u64 {
|
||
data.iter().sum()
|
||
}
|
||
|
||
for _ in 0..39 {
|
||
sum_reference += sum_by_reference(&balances);
|
||
}
|
||
|
||
// INEFFICIENT: 49,322 CU - Clone data (3.5% more expensive)
|
||
// WARNING: Runs out of memory at 40+ iterations!
|
||
fn sum_by_value(data: Vec<u64>) -> u64 {
|
||
data.iter().sum()
|
||
}
|
||
|
||
for _ in 0..39 {
|
||
sum_clone += sum_by_value(balances.clone());
|
||
}
|
||
```
|
||
|
||
**Memory concern**: Solana programs have a 32KB heap using a bump allocator that **never frees memory** during transaction execution. Excessive cloning leads to out-of-memory errors.
|
||
|
||
**Best practice**: Always pass by reference (`&T`) unless you explicitly need ownership transfer. Use `Copy` types for small data.
|
||
|
||
### 7. Checked Math vs Unchecked Operations
|
||
|
||
Checked arithmetic adds safety at the cost of compute units.
|
||
|
||
**Comparison:**
|
||
|
||
```rust
|
||
let mut count: u64 = 1;
|
||
|
||
// 97,314 CU - Checked multiplication with overflow protection
|
||
for _ in 0..12000 {
|
||
count = count.checked_mul(2).expect("overflow");
|
||
}
|
||
|
||
// 85,113 CU - Bit shift operation (12% savings)
|
||
// Equivalent to multiply by 2, but unchecked
|
||
for _ in 0..12000 {
|
||
count = count << 1;
|
||
}
|
||
```
|
||
|
||
**Trade-off**: Unchecked operations are faster but risk overflow bugs that can lead to serious security vulnerabilities.
|
||
|
||
**Best practice**:
|
||
- Use checked math by default for safety
|
||
- Profile your program to identify hot paths
|
||
- Only switch to unchecked math when:
|
||
- You've proven overflow is impossible
|
||
- CU savings are critical
|
||
- You've added overflow tests
|
||
|
||
**Compiler configuration** (in Cargo.toml):
|
||
|
||
```toml
|
||
[profile.release]
|
||
overflow-checks = true # Keep overflow checks even in release mode
|
||
```
|
||
|
||
## Framework Comparison
|
||
|
||
Different implementation approaches offer varying trade-offs between developer experience, safety, and performance.
|
||
|
||
| Implementation | Binary Size | Deploy Cost | Init CU | Increment CU |
|
||
|---------------|-------------|-------------|---------|--------------|
|
||
| **Anchor** | 265,677 bytes | 1.85 SOL | 6,302 | 946 |
|
||
| **Anchor Zero-Copy** | Same | 1.85 SOL | 5,020 | ~1,254 |
|
||
| **Native Rust** | 48,573 bytes | 0.34 SOL | - | 843 |
|
||
| **Unsafe Rust** | 973 bytes | 0.008 SOL | - | 5 |
|
||
| **Assembly (SBPF)** | 1,389 bytes | 0.01 SOL | - | 4 |
|
||
| **C** | 1,333 bytes | 0.01 SOL | - | 5 |
|
||
|
||
**Key insights:**
|
||
|
||
- **Anchor**: Best developer experience, automatic account validation, but highest CU and deployment costs
|
||
- **Anchor Zero-Copy**: Significant CU improvement over standard Anchor with minimal code changes
|
||
- **Native Rust**: 11% CU savings over Anchor, 82% smaller deployment size, moderate complexity
|
||
- **Unsafe Rust**: 99% CU savings, minimal size, but requires extreme care and deep expertise
|
||
- **Assembly/C**: Maximum optimization possible, but very difficult to develop and maintain
|
||
|
||
**Recommendation**: Start with Anchor or native Rust. Optimize hot paths with zero-copy. Only consider unsafe Rust or lower-level languages for critical performance bottlenecks after profiling.
|
||
|
||
## Advanced Optimization Techniques
|
||
|
||
### 1. Compiler Flags
|
||
|
||
Configure optimization in `Cargo.toml`:
|
||
|
||
```toml
|
||
[profile.release]
|
||
opt-level = 3 # Maximum optimization
|
||
lto = "fat" # Full link-time optimization
|
||
codegen-units = 1 # Single codegen unit for better optimization
|
||
overflow-checks = true # Keep safety checks despite performance cost
|
||
```
|
||
|
||
**Trade-offs**:
|
||
- `overflow-checks = false`: Saves CU but removes critical safety checks
|
||
- Higher `opt-level`: Better performance but slower compilation
|
||
- `lto = "fat"`: Maximum optimization but much slower builds
|
||
|
||
### 2. Function Inlining
|
||
|
||
Control function inlining to balance CU usage and stack space:
|
||
|
||
```rust
|
||
// Force inlining - saves CU by eliminating function call overhead
|
||
#[inline(always)]
|
||
fn add(a: u64, b: u64) -> u64 {
|
||
a + b
|
||
}
|
||
|
||
// Prevent inlining - saves stack space at the cost of CU
|
||
#[inline(never)]
|
||
pub fn complex_operation() {
|
||
// Large function body
|
||
}
|
||
```
|
||
|
||
**Trade-off**: Inlining saves CU but increases stack usage. Solana has a 4KB stack limit, so excessive inlining can cause stack overflow.
|
||
|
||
### 3. Alternative Entry Points
|
||
|
||
The standard Solana entry point adds overhead. Alternatives:
|
||
|
||
**Standard entry point:**
|
||
```rust
|
||
use solana_program::entrypoint;
|
||
entrypoint!(process_instruction);
|
||
```
|
||
|
||
**Minimal entry points:**
|
||
- [solana-nostd-entrypoint](https://github.com/cavemanloverboy/solana-nostd-entrypoint): Ultra-minimal entry using unsafe Rust
|
||
- [eisodos](https://github.com/anza-xyz/eisodos): Alternative minimal entry point
|
||
|
||
**Warning**: These require deep understanding of Solana internals and unsafe Rust. Only use for extreme optimization needs.
|
||
|
||
### 4. Custom Heap Allocators
|
||
|
||
Solana's default bump allocator never frees memory during transaction execution.
|
||
|
||
**Problem:**
|
||
```rust
|
||
// This will eventually run out of heap space (32KB limit)
|
||
for _ in 0..1000 {
|
||
let v = vec![0u8; 1024]; // Each iteration uses more heap
|
||
// Memory is never freed!
|
||
}
|
||
```
|
||
|
||
**Solution - Custom allocators:**
|
||
|
||
- **smalloc**: Used by Metaplex programs, provides better memory management
|
||
- Prevents out-of-memory errors in memory-intensive operations
|
||
|
||
**Implementation** (advanced):
|
||
```rust
|
||
#[global_allocator]
|
||
static ALLOCATOR: custom_allocator::CustomAllocator = custom_allocator::CustomAllocator;
|
||
```
|
||
|
||
### 5. Boxing and Heap Allocation
|
||
|
||
Heap operations cost more CU than stack operations.
|
||
|
||
```rust
|
||
// Stack allocation - faster
|
||
let data = [0u8; 100];
|
||
|
||
// Heap allocation - slower, uses more CU
|
||
let data = Box::new([0u8; 100]);
|
||
```
|
||
|
||
**Best practice**: Avoid `Box`, `Vec`, and other heap allocations when stack allocation is possible and doesn't risk overflow.
|
||
|
||
## Measuring Compute Units
|
||
|
||
### Using sol_log_compute_units()
|
||
|
||
Built-in logging function to track CU consumption:
|
||
|
||
```rust
|
||
use solana_program::log::sol_log_compute_units;
|
||
|
||
pub fn my_instruction(ctx: Context<MyContext>) -> Result<()> {
|
||
sol_log_compute_units(); // Log remaining CU
|
||
|
||
// ... do some work ...
|
||
|
||
sol_log_compute_units(); // Log remaining CU again
|
||
Ok(())
|
||
}
|
||
```
|
||
|
||
**Output in transaction logs:**
|
||
```
|
||
Program consumption: 200000 units remaining
|
||
Program consumption: 195432 units remaining
|
||
```
|
||
|
||
**CU used = 200000 - 195432 = 4,568 CU**
|
||
|
||
### compute_fn! Macro
|
||
|
||
Convenient macro for measuring specific code blocks (costs 409 CU overhead):
|
||
|
||
```rust
|
||
#[macro_export]
|
||
macro_rules! compute_fn {
|
||
($msg:expr=> $($tt:tt)*) => {
|
||
::solana_program::msg!(concat!($msg, " {"));
|
||
::solana_program::log::sol_log_compute_units();
|
||
let res = { $($tt)* };
|
||
::solana_program::log::sol_log_compute_units();
|
||
::solana_program::msg!(concat!(" } // ", $msg));
|
||
res
|
||
};
|
||
}
|
||
```
|
||
|
||
**Usage:**
|
||
|
||
```rust
|
||
let result = compute_fn! { "My expensive operation" =>
|
||
expensive_computation()
|
||
};
|
||
```
|
||
|
||
**Output:**
|
||
```
|
||
Program log: My expensive operation {
|
||
Program consumption: 195432 units remaining
|
||
Program consumption: 180123 units remaining
|
||
Program log: } // My expensive operation
|
||
```
|
||
|
||
**Actual CU = (195432 - 180123) - 409 (macro overhead) = 14,900 CU**
|
||
|
||
### Using Mollusk Bencher
|
||
|
||
For native Rust programs, use Mollusk's built-in benchmarking (see main SKILL.md for details).
|
||
|
||
## Anti-Patterns to Avoid
|
||
|
||
### 1. Excessive Logging
|
||
|
||
```rust
|
||
// BAD: Logging in production
|
||
msg!("Processing user {}", user_pubkey);
|
||
msg!("Amount: {}", amount);
|
||
msg!("Timestamp: {}", Clock::get()?.unix_timestamp);
|
||
```
|
||
|
||
**Solution**: Remove logging or use conditional compilation:
|
||
|
||
```rust
|
||
#[cfg(feature = "debug")]
|
||
msg!("Processing user {}", user_pubkey);
|
||
```
|
||
|
||
### 2. Large Data Types for Small Values
|
||
|
||
```rust
|
||
// BAD: Using u64 when u8 suffices
|
||
pub struct Config {
|
||
pub fee_percentage: u64, // Only 0-100
|
||
pub max_items: u64, // Only 0-255
|
||
}
|
||
|
||
// GOOD: Use smallest type
|
||
pub struct Config {
|
||
pub fee_percentage: u8, // 0-100
|
||
pub max_items: u8, // 0-255
|
||
}
|
||
```
|
||
|
||
### 3. Cloning Large Structures
|
||
|
||
```rust
|
||
// BAD: Unnecessary clone
|
||
fn process_data(data: Vec<u8>) -> Result<()> {
|
||
let copy = data.clone(); // Wastes CU and heap
|
||
// ...
|
||
}
|
||
|
||
// GOOD: Pass by reference
|
||
fn process_data(data: &[u8]) -> Result<()> {
|
||
// Work directly with reference
|
||
}
|
||
```
|
||
|
||
### 4. Repeated PDA Derivation
|
||
|
||
```rust
|
||
// BAD: Finding bump every time
|
||
#[account(
|
||
seeds = [b"vault"],
|
||
bump // Finds bump on every call!
|
||
)]
|
||
pub vault: Account<'info, Vault>,
|
||
|
||
// GOOD: Use saved bump
|
||
#[account(
|
||
seeds = [b"vault"],
|
||
bump = vault.bump // Uses saved bump
|
||
)]
|
||
pub vault: Account<'info, Vault>,
|
||
```
|
||
|
||
### 5. Unnecessary Boxing
|
||
|
||
```rust
|
||
// BAD: Boxing adds heap overhead
|
||
let value = Box::new(calculate_value());
|
||
|
||
// GOOD: Keep on stack
|
||
let value = calculate_value();
|
||
```
|
||
|
||
### 6. String Operations
|
||
|
||
```rust
|
||
// BAD: String concatenation and formatting
|
||
let message = format!("User {} sent {} tokens", user, amount);
|
||
msg!(&message);
|
||
|
||
// GOOD: Use separate logs or remove entirely
|
||
user.log();
|
||
amount.log();
|
||
```
|
||
|
||
### 7. Deep CPI Chains
|
||
|
||
Each CPI adds significant overhead. Avoid unnecessary indirection:
|
||
|
||
```rust
|
||
// BAD: Unnecessary CPI
|
||
invoke(
|
||
&my_helper_program::process(),
|
||
&accounts,
|
||
)?;
|
||
|
||
// GOOD: Direct implementation
|
||
process_directly(&accounts)?;
|
||
```
|
||
|
||
### 8. Not Using Zero-Copy for Large Accounts
|
||
|
||
```rust
|
||
// BAD: Large account with standard serialization
|
||
#[account]
|
||
pub struct LargeData {
|
||
pub items: [u64; 1000], // Expensive to serialize/deserialize
|
||
}
|
||
|
||
// GOOD: Use zero-copy
|
||
#[account(zero_copy)]
|
||
#[repr(C)]
|
||
pub struct LargeData {
|
||
pub items: [u64; 1000], // Direct memory access
|
||
}
|
||
```
|
||
|
||
## Best Practices Summary
|
||
|
||
1. **Minimize or eliminate logging** in production code
|
||
2. **Use zero-copy** for accounts with large data structures
|
||
3. **Cache PDA bumps** - derive once, store in account, reuse
|
||
4. **Choose smallest data types** that meet your requirements
|
||
5. **Pass by reference** instead of cloning data
|
||
6. **Profile before optimizing** - measure CU usage to identify bottlenecks
|
||
7. **Consider native Rust** over Anchor for performance-critical programs
|
||
8. **Use `vec![]` initialization** instead of repeated `push()` calls
|
||
9. **Avoid unnecessary CPIs** - use direct operations when safe
|
||
10. **Balance safety vs performance** - don't sacrifice security without careful analysis
|
||
11. **Test CU usage** regularly - include benchmarks in your test suite
|
||
12. **Use checked math by default** - only optimize to unchecked when proven safe
|
||
13. **Minimize heap allocations** - prefer stack when possible
|
||
14. **Remove or conditionally compile debug code** for production builds
|
||
15. **Consider zero-copy for frequently updated accounts** - 50%+ CU savings
|
||
|
||
## Additional Resources
|
||
|
||
### Official Documentation
|
||
- [How to Optimize Compute](https://solana.com/developers/guides/advanced/how-to-optimize-compute)
|
||
- [Solana Compute Budget Documentation](https://github.com/solana-labs/solana/blob/090e11210aa7222d8295610a6ccac4acda711bb9/program-runtime/src/compute_budget.rs#L26-L87)
|
||
|
||
### Code Examples and Tools
|
||
- [solana-developers/cu_optimizations](https://github.com/solana-developers/cu_optimizations) - Official examples with benchmarks
|
||
- [hetdagli234/optimising-solana-programs](https://github.com/hetdagli234/optimising-solana-programs) - Community optimization examples
|
||
|
||
### Video Guides
|
||
- [How to optimize CU in programs](https://www.youtube.com/watch?v=7CbAK7Oq_o4)
|
||
- [Program optimization Part 1](https://www.youtube.com/watch?v=xoJ-3NkYXfY)
|
||
- [Program optimization Part 2 - Advanced](https://www.youtube.com/watch?v=Pwly1cOa2hg)
|
||
- [Writing Solana programs in Assembly](https://www.youtube.com/watch?v=eacDC0VgyxI)
|
||
|
||
### Technical Articles
|
||
- [RareSkills: Solana Compute Unit Price](https://rareskills.io/post/solana-compute-unit-price)
|
||
- [Understanding Solana Compute Units](https://www.helius.dev/blog/priority-fees-understanding-solanas-transaction-fee-mechanics)
|
||
|
||
### Advanced Tools
|
||
- [solana-nostd-entrypoint](https://github.com/cavemanloverboy/solana-nostd-entrypoint) - Minimal entry point
|
||
- [Mollusk](https://github.com/anza-xyz/mollusk) - Fast testing with CU benchmarking
|