Multithreaded calls to Local::now() take a lot of time, which is abnormal.

[chan369]

When Local::now() is called 10,000 times in a single thread, it barely takes any time. However, when called in a multithreaded environment, it takes significantly more time. Below is the example code:
fn test_proc()
{
let i=Instant::now();
for _ in 0..10000
{
let v=Local::now();
}
let d=i.elapsed();
println!("time:{}",d.as_millis());
}

fn main()
{
println!("first time");
for _ in 0..1
{
thread::spawn(test_proc);
}
sleep(Duration::from_secs(5));
println!("second time");
for _ in 0..10
{
thread::spawn(test_proc);
}
sleep(Duration::from_secs(5));
}

Output:
first time
time:4
second time
time:362
time:363
time:363
time:365
time:364
time:364
time:365
time:365
time:364
time:365

What's happening here?

[djc]

I'm guessing there might be a bunch of contention on the RefCell that we use to cache the timezone data?

What platform/OS is this?

[chan369]

I'm guessing there might be a bunch of contention on the RefCell that we use to cache the timezone data?

What platform/OS is this?

Windows 10 professional

[djc]

My former comment assumed Unix. For Windows, I'm not sure what's going on -- I don't think there are any locks in chrono's Windows code so I'm guessing something in the OS API is causing contention?

The Windows code is here:

https://github.com/chronotope/chrono/blob/main/src/offset/local/windows.rs

I think we'd be calling into <Local as TimeZone>::offset_from_utc_datetime().

@ChrisDenton would you happen to have any knowledge of this stuff (or know someone who does)?

[ChrisDenton]

I've not looked into it yet but my immediate reaction in such cases is to always check allocations first. The built-in Windows allocator is synchronous so a lot of threads allocating at the same time is going to be slow.

Try and see if using mimalloc solves the issue.