Simplex version
0.7
What happened?
I was building a very large .simf contract that actually takes >1 second just to compile once with simc. I found that every Simplex test using this contract took 50 seconds or longer, even when testing very basic transactions (fund/spend with one single transaction, or even fund/deliberately fail spend).
Claude analyzed this and concluded that
|
fn load(&self) -> Result<CompiledProgram, ProgramError> { |
is inefficient because it isn't cached/memoized, and in particular that it recompiles the entire contract on every call. The load() here gets called multiple times per test apparently for reasons including fee estimation; although I don't have a specific count, it actually appears that load() is called dozens of times for each individual test and ends up making complex contracts very unnecessarily slow to test.
Claude proposed a patch that would cache the results of compilation. It argues that the efficiency is improved
by caching the first compile per Program (shared across clones via Arc<OnceLock<CompiledProgram>> -- CompiledProgram is cheap to clone, its heavy field is itself an Arc) and reusing it thereafter. source/arguments never change after Program::new, so this is safe.
I'm happy to share its solution or just leave this up to Simplex developers to think of an architecturally appropriate way to cache the compilation to avoid repeating it. In my test cases, a change to this behavior appeared to make each individual test about twice as fast, or sometimes gave even larger improvements on tests involving very complex SimplicityHL contracts!
Minimal reproduction steps
Just running simplex test takes a long time (although "a long time" is subjective or relative in this context).
Simplex version
0.7
What happened?
I was building a very large
.simfcontract that actually takes >1 second just to compile once withsimc. I found that every Simplex test using this contract took 50 seconds or longer, even when testing very basic transactions (fund/spend with one single transaction, or even fund/deliberately fail spend).Claude analyzed this and concluded that
smplx/crates/sdk/src/program/core.rs
Line 310 in b7f38a0
is inefficient because it isn't cached/memoized, and in particular that it recompiles the entire contract on every call. The
load()here gets called multiple times per test apparently for reasons including fee estimation; although I don't have a specific count, it actually appears thatload()is called dozens of times for each individual test and ends up making complex contracts very unnecessarily slow to test.Claude proposed a patch that would cache the results of compilation. It argues that the efficiency is improved
I'm happy to share its solution or just leave this up to Simplex developers to think of an architecturally appropriate way to cache the compilation to avoid repeating it. In my test cases, a change to this behavior appeared to make each individual test about twice as fast, or sometimes gave even larger improvements on tests involving very complex SimplicityHL contracts!
Minimal reproduction steps
Just running
simplex testtakes a long time (although "a long time" is subjective or relative in this context).