Performance sensitivity of the CP-SAT solver to alternative memory allocators

[gregy4]

Hi,

I’d like to share an observation regarding CP-SAT and its sensitivity to alternative memory allocators.

On large multi-threaded runs (16 workers), I noticed that simply changing the allocator (glibc malloc vs jemalloc vs tcmalloc) can significantly influence solver behavior — not only runtime characteristics, but also which subsolvers become active (e.g., LP engagement), the search trajectory, and overall dynamics of the run.

This seems to affect more than just raw speed; it appears to shift the internal portfolio balance in noticeable ways.

I’m not reporting a bug — just a performance observation.

Of course, due to the stochastic and portfolio nature of CP-SAT, a rigorous evaluation would require many instances and repeated runs to quantify the net benefit statistically. My observation is simply that allocator choice can materially change solver behavior, which might be relevant for performance portability and reproducibility.

I’m curious:

Have you experimented with different memory allocators for CP-SAT?

Is allocator sensitivity something you’re aware of in the context of portfolio search?

Do the official binaries rely purely on system malloc, or is an alternative allocator used internally?

I’m happy to share logs or more detailed data if useful.

Jan

[lperron]

Interesting,

Internally, I believe we use some version of tcmalloc.

But we rely on the default malloc, (tcmalloc internally, glibc on linux, I do not know exactly which one on mac) and by experience, the windows one is bad.