Solana Development Utilities
A collection of utilities and macros to enhance Solana program development, focusing on compute unit logging and instruction discriminant generation.
Features
- Log CU for functions and code blocks
- Parse logs, with correction for measurement overhead*
- Utility functions for Solana-specific operations
- Generate const instruction discriminants for Anchor programs
*Read below for important notes on CU measurement correction.
Recommended Usage
[]
= "0.1.5"
[]
= []
use compute_fn;
with Cargo.toml
:
Then if you want to enable logging, compile with:
If you build normally, the compute_fn
attribute will be stripped from the code and introduces no overhead.
Then
parses all your logs to log_parsed.json
.
sol-dev-proc-macros

[]
= "0.1.5"
Usage
use compute_fn;
Produces log entries:
sol-dev-macros

[]
= "0.1.5"
Usage
use compute_fn;
compute_fn!;
sol-dev-cli

Usage
The CLI can be used to parse the logs generated by the compute unit logging macros. The logs can be parsed from a file or a directory containing multiple log files.
This parses logs into JSON that looks like this:
Measurement | Description |
---|---|
naive_local | Raw CU consumed within the function, excluding its children, including measurement overhead |
naive_global | Raw CU consumed within the function, excluding its children, including measurement overhead |
local | Adjusted CU consumed within the function, excluding its children, excluding measurement overhead |
global | Adjusted CU consumed within the function, excluding its children, excluding measurement overhead |
Important Notes on CU measurement
Of course measuring CU itself costs CU. Some of this extra cost we can account for, some of it we can't.
What we can account for is the cost of the msg!
macro and sol_log_compute_units!
macro.
Some of this cost goes to the caller of the function, and some of it is internalized by the function itself.
We can correct for this cost with some simple arithmetic, which is reflected in the 'local' and 'global' measurements.
What we can't account for is that this macro will cause the compiler to generate different code, which will have a different CU cost. This unaccounted difference is why we provide both naive and adjusted measurements. Example:
use compute_fn;
Normally, my_inner_function
would likely be inlined into my_function
, turning this into a single function call.
Using compute_fn
will prevent inlining, causing two function calls.
We cannot account for this difference easily, so user discretion is advised.
In practice, these differences are significant, so be weary of this. My advice is to only use measurements to quantify the relative cost of different code paths, not the absolute cost.
sol-dev-utils

[]
= "0.1.5"
Usage
use anchor_discriminant;
match discriminant
Handles the global namespace automatically if no namespace is provided.
Contributing
Contributions are welcome! Please open an issue or submit a pull request.
License
This project is licensed under the MIT License - see the LICENSE file for details.