mimalloc_rust is a four line change to the allocator under your Rust program

The entire integration is a static declaration

The usage section of the README is three lines of Rust, and that is the whole story of how the crate is adopted.

use mimalloc::MiMalloc;

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

Declaring a type as the global allocator is the standard Rust mechanism for replacing the system allocator, and the crate provides the type. There is no runtime setup, no initialisation call, and no configuration in code.

The package metadata describes it as a performance and security oriented drop-in allocator, and the crate is published on crates.io as mimalloc, with the documentation on docs.rs. The repository is separate from the upstream C project, which lives at microsoft/mimalloc and is consumed as a dependency rather than reimplemented.

The authors listed in the manifest are Octavian Oncescu, Vincent Rouillé and Thom Chiovoloni, and the keywords are mimalloc, allocator, encrypted-heap and performance, with the categories memory-management and api-bindings. The Rust edition is 2018 and the licence is MIT.

The version numbering tells you where this sits. The crate is at 0.1.52, with recent releases v0.1.50, v0.1.51 and v0.1.52 in April and May 2026, and the last push to the repository was on 2026-06-30.

A sys crate holds the C core, and it is vendored as a submodule

The repository layout shows a two crate structure, and the Cargo.toml makes it explicit.

The workspace has three members: libmimalloc-sys, libmimalloc-sys/sys-test, and test-override-with-dylib. The main package depends on libmimalloc-sys with a path and a version of 0.1.49, and with default-features turned off, so that the feature selection happens entirely in the wrapper crate.

The separation is the usual one for a C library with a Rust binding. The sys crate is a thin, unsafe layer over the C API, and the wrapper crate is the safe Rust surface on top of it. The feature list in the manifest is almost entirely a pass through, with each entry forwarding to the same named feature on libmimalloc-sys, for example secure maps to libmimalloc-sys/secure and v2 maps to libmimalloc-sys/v2.

There is a .gitmodules file at the top of the repository, which means the upstream mimalloc sources come in as a git submodule rather than being vendored as a tarball. That is a choice with consequences. A submodule means the exact upstream revision is recorded in the repository, so a build is reproducible against a known C source, and updating the allocator means moving the submodule pointer rather than merging C code.

The test-override-with-dylib member and the override feature point at a testing scenario: the override feature lets a dynamic library take over allocation at runtime, which is how you would check that a binary really does use the allocator you think it uses.

Secure mode costs about ten percent, by upstream's own numbers

The secure feature is the one with a stated cost, and the README is careful about where the number comes from.

Using secure mode adds guard pages, randomized allocation, encrypted free lists and similar hardening. The performance penalty is usually around 10% according to mimalloc's own benchmarks, which is a reference to upstream measurements rather than a claim made by this wrapper.

Enabling it is a feature flag in the dependency declaration.

[dependencies]
mimalloc = { version = "*", features = ["secure"] }

The reasoning behind the feature is worth understanding, because it explains the trade-off. A general purpose allocator keeps free lists of memory it has handed out and later reclaimed. In a normal process, a bug that lets an attacker read beyond a buffer may let them read a free list, and a free list contains pointers into the heap, which is a way to defeat address space layout randomisation. Randomised allocation moves things around so that a stale pointer does not point at anything predictable, and encrypted free lists mean that the pointer values stored in the free list are not usable even if they are read.

That is a defence against a specific class of memory corruption bug, and it is why the cost is a flat percentage rather than a rounding error. The extra work is per free and per reuse, not per allocation of new pages.

v2 and v3, and a feature list that is mostly pass through

The default backend is mimalloc v3, and switching to v2 is a feature flag.

[dependencies]
mimalloc = { version = "*", features = ["v2"] }

That flag exists because the wrapper tracks upstream, and upstream has moved on. Choosing v2 pins the crate to the older allocator design, which is the option to reach for if a dependency or a benchmark tells you the newer backend behaves differently in your workload.

The rest of the feature list gives a good picture of what the C library can be asked to do. There is debug and debug_in_debug, which turn on the library's own diagnostics in debug builds. There is local_dynamic_tls and win_direct_tls, which control where the thread local storage for the allocator lives, a detail that matters on Windows and in environments with unusual TLS models. There is no_thp, which disables transparent huge pages. There is extended, and nightly_allocator_api, which is defined as the extended feature and therefore turns it on.

That last one is the one to look at twice. The nightly_allocator_api feature is a separate opt in rather than something bundled with the default set, and the name says what it is, an allocator API that is not yet stable in the Rust toolchain. Enabling it ties your build to a nightly compiler, which is a decision with consequences well beyond the allocator.

The default feature set is empty, so a plain dependency gets mimalloc v3 with none of the extras.

A C compiler is a hard requirement of the build

The requirements section is one sentence, and it matters more than it looks.

A C compiler is required for building mimalloc with cargo. Since the upstream sources arrive as a submodule and are compiled as part of the build, the C toolchain is not optional and not merely needed for a developer build. It is needed wherever the crate is compiled, which means in your CI images and in whatever environment produces your release binaries.

This is the main practical difference between this crate and a pure Rust allocator such as the ones the standard library can use, and it is the reason to check your build images first. A container that ships a prebuilt Rust binary is unaffected, but a minimal build image that installs only a Rust toolchain will fail at the build step with a C compilation error rather than a missing allocator message.

The failure mode is confusing when you have not seen it, because cargo reports it as a build failure in a dependency rather than as a missing toolchain requirement. Knowing that the fix is to install a C compiler, rather than to change allocator configuration, saves the debugging session.

The published package also declares the type of crate it is. The categories are memory-management and api-bindings, and the description calls it a performance and security oriented drop-in allocator, which is the same claim as the README.

When the system allocator is the better answer

Three situations argue against adding this dependency.

The first is a build environment without a C compiler. As described above, the C core is compiled by cargo, so a toolchain that only provides Rust cannot build the crate. For a project that must build in a hermetic, minimal environment, that is disqualifying.

The second is a program that is already allocation-insensitive. The standard allocator on a modern platform is a reasonable default, and swapping it out adds a dependency, a C build and a behaviour change to a binary that may not benefit. The decision should be driven by a profile that shows allocation is actually a bottleneck, or by a security requirement, not by the general appeal of a faster allocator.

The third is a program that must not have a C library linked at all, for instance something built for a constrained or freestanding target where the platform has its own allocator contract.

There is also a smaller trade-off in the features themselves. The secure mode is priced at around ten percent by upstream's own benchmarks, and that is a real cost for a service whose throughput is the product. The hardened mode is worth it when untrusted input reaches the allocator, and it is not worth it in a batch job that processes trusted data.

And the version choice deserves to be made on purpose. The default is v3, v2 exists as an escape hatch, and the nightly_allocator_api feature will tie the build to a nightly toolchain if you turn it on.

Editorial conclusion

mimalloc_rust suits a Rust service whose allocation behaviour is visible in profiles, or a team that wants the hardened secure mode for a process handling untrusted input, since the change to adopt it is a single static declaration and the secure feature costs a documented percentage of throughput. It is the wrong choice if your build environment has no C compiler, since the C core has to be built by cargo, and the wrong choice for a binary that must stay dependency free or fully static in a way the sys crate cannot satisfy. Before adopting it, confirm a C toolchain is present in your build and release images, and decide between the default mimalloc v3 and the v2 backend deliberately, because the feature is a one way choice in the dependency declaration.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. purpleprotocol/mimalloc_rust on GitHub
4. README
5. Releases