The preferred usage is including <mimalloc.h>
, linking with the shared- or static library, and using the mi_malloc
API exclusively for allocation. For example,
mimalloc uses only safe OS calls (mmap
and VirtualAlloc
) and can co-exist with other allocators linked to the same program. If you use cmake
, you can simply use:
in your CMakeLists.txt
to find a locally installed mimalloc. Then use either:
to link with the shared (dynamic) library, or:
to link with the static library. See test\CMakeLists.txt
for an example.
You can pass environment variables to print verbose messages (MIMALLOC_VERBOSE=1
) and statistics (MIMALLOC_SHOW_STATS=1
) (in the debug version):
The above model of using the mi_
prefixed API is not always possible though in existing programs that already use the standard malloc interface, and another option is to override the standard malloc interface completely and redirect all calls to the mimalloc library instead.
See Overriding Malloc for more info.
You can set further options either programmatically (using mi_option_set
), or via environment variables.
MIMALLOC_SHOW_STATS=1
: show statistics when the program terminates.MIMALLOC_VERBOSE=1
: show verbose messages.MIMALLOC_SHOW_ERRORS=1
: show error and warning messages.MIMALLOC_LARGE_OS_PAGES=1
: use large OS pages when available; for some workloads this can significantly improve performance. Use MIMALLOC_VERBOSE
to check if the large OS pages are enabled – usually one needs to explicitly allow large OS pages (as on Windows and Linux).MIMALLOC_EAGER_REGION_COMMIT=1
: on Windows, commit large (256MiB) regions eagerly. On Windows, these regions show in the working set even though usually just a small part is committed to physical memory. This is why it turned off by default on Windows as it looks not good in the task manager. However, in reality it is always better to turn it on as it improves performance and has no other drawbacks.