The value of integrating
ethrex only runs jemalloc when you ask for it: cmd/ethrex/ethrex.rs gates the #[global_allocator] on #[cfg(all(feature = "jemalloc", not(target_env = "msvc")))]. A default cargo build, and every MSVC build regardless of features, therefore runs on the platform allocator instead — glibc on Linux, the Heap on Windows.
That gap sits on top of a real allocation load. An execution client following the chain replays every block through the EVM and writes the resulting state through rocksdb (rocksdb = "0.24.0"), and rayon = "1.10.0" spreads that work across a pool, so the thread that frees a chunk of state is usually not the thread that allocated it. The cross-thread free path is on the hot path of a sync, for whichever allocator the build happened to land on.
rusty_alloc is one allocator on every target with 8,851 downloads on crates.io, in safe Rust with no build script — so there is no MSVC exception to carve out. Against jemalloc the rusty_alloc README's callgrind arms measure 0.84x, 0.89x and 0.98x whole-program instructions on lua, perl and sqlite under LD_PRELOAD.
Not asking you to drop the jemalloc feature — this would be a second one beside it.
How to integrate
You already have the pattern, since jemalloc is opt-in:
[features]
rusty-alloc = ["dep:rusty_alloc-api"] # opt in, like `jemalloc`
[dependencies]
rusty_alloc-api = { version = "2.1", optional = true }#[cfg(all(feature = "rusty-alloc", not(feature = "jemalloc")))]
#[global_allocator]
static ALLOC: rusty_alloc_api::RustyAlloc = rusty_alloc_api::RustyAlloc;
Nothing else moves: same EVM, same storage, same RPC. It is off unless selected, and unlike the jemalloc arm it needs no target_env guard, so one CI job can cover it on all three platforms.
Remade With Rust & MATA
We are rebuilding common C dependencies in safe Rust — allocators, codecs, parsers, compression, identity and storage — so a project can take C out of its build without giving up performance. The rest of the org is at https://github.com/Remade-With-Rust if anything else fits your tree. If this is a poor fit, please close the issue.
The value of integrating
ethrex only runs jemalloc when you ask for it:
cmd/ethrex/ethrex.rsgates the#[global_allocator]on#[cfg(all(feature = "jemalloc", not(target_env = "msvc")))]. A defaultcargo build, and every MSVC build regardless of features, therefore runs on the platform allocator instead — glibc on Linux, the Heap on Windows.That gap sits on top of a real allocation load. An execution client following the chain replays every block through the EVM and writes the resulting state through rocksdb (
rocksdb = "0.24.0"), andrayon = "1.10.0"spreads that work across a pool, so the thread that frees a chunk of state is usually not the thread that allocated it. The cross-thread free path is on the hot path of a sync, for whichever allocator the build happened to land on.rusty_alloc is one allocator on every target with 8,851 downloads on crates.io, in safe Rust with no build script — so there is no MSVC exception to carve out. Against jemalloc the rusty_alloc README's callgrind arms measure 0.84x, 0.89x and 0.98x whole-program instructions on lua, perl and sqlite under
LD_PRELOAD.Not asking you to drop the jemalloc feature — this would be a second one beside it.
How to integrate
You already have the pattern, since jemalloc is opt-in:
Nothing else moves: same EVM, same storage, same RPC. It is off unless selected, and unlike the jemalloc arm it needs no
target_envguard, so one CI job can cover it on all three platforms.Remade With Rust & MATA
We are rebuilding common C dependencies in safe Rust — allocators, codecs, parsers, compression, identity and storage — so a project can take C out of its build without giving up performance. The rest of the org is at https://github.com/Remade-With-Rust if anything else fits your tree. If this is a poor fit, please close the issue.