Blocking behavior on Windows when allocating inside a loop on multiple threads

[c-antin]

I've been porting a simple PHP benchmark of repeated str_replace/preg_replace to Rust (that I scaled up to have 1s runtime on my machine). First I thought it's a problem with the regex crate (more details can be found here).
But it seems to be an issue on Windows if the allocator is shared between threads (vs processes).

use std::time::Instant;

use regex::Regex;

fn main() {
    let mut args = std::env::args();
    let _ = args.next();
    let arg1 = args.next();
    if arg1.is_none() {
        panic!("arg1 missing!");
    }
    let n = arg1.unwrap().parse().unwrap();
    let ts = Instant::now();
    let mut handles = Vec::with_capacity(n);
    for _ in 0..n {
        handles.push(std::thread::spawn(|| {
            let mut subject = "#".to_string();
            let search = Regex::new(&regex::escape("#")).unwrap();
            let replace = "benchmark#";

            let ts = Instant::now();
            for _ in 0..38000 {
                subject = search.replace_all(&subject, replace).to_string();
            }
            println!("thread {}", ts.elapsed().as_secs_f32());
        }));
    }

    for handle in handles {
        handle.join().unwrap();
    }
    println!("total {}", ts.elapsed().as_secs_f32());
}

I expected to see this happen: total runtime at most that of the slowest thread

Instead, this happened: total runtime is as if all threads were run in sequence

I've tested it on 3 distinct Windows machines (same result) and on a macOS machine (no sequential runtime).

Meta

rustc --version --verbose:

rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-pc-windows-msvc
release: 1.70.0
LLVM version: 16.0.2

[ChrisDenton]

If you don't override it, then std on Windows uses HeapAlloc with the default process heap. This is indeed serialized.

I'd suggest trying with mimalloc and seeing if the results are better.

[c-antin]

The results with mimalloc are significantly better, thanks!