Jack Thomson

@sansyrox Yes but 0.5.3 wasn't using actix, before the upgrade of pyo3 and async py it was hitting 27k

> Nice, thanks for pushing this forward! > > I took a look at the code for `fast-counter`, and had a couple of thoughts: > > * I think `THREAD_ID`...

Hey @jonhoo been looking into this and a few thoughts and findings: - I tested using the `ThreadID::as_u64` this proved to be significantly slower, a quick look in godbolt it...

> Looks like there are some CI failures now? Saw these, I'll take a look at resolving them when I get a chance! Thanks for running the workflow

Hi Jon, sorry been away for a while. This looks an interesting problem, and does seem something to do with the reclamation not running for some reason. I'll definitely take...

Hey sorry I didn't update here, been pretty busy at work. So a couple of new findings: - Replicating this in Axum webserver the issue is gone and memory behaves...

Thanks for taking a look, when you test with hyper can you use a custom allocator such as jemalloc so we can try eliminate heap fragmentation being a potential cause

Sure this is the code I was using ```rust use lazy_static::lazy_static; use axum::{response::Html, routing::get, Router}; use std::net::SocketAddr; use std::sync::Mutex; use bytesize::ByteSize; use sysinfo::{get_current_pid, ProcessExt, ProcessRefreshKind, RefreshKind, System, SystemExt}; use tikv_jemallocator::Jemalloc;...

I don't exact numbers, but what I found was memory increased the first 2 cycles then eventually dropped and stayed consistent

So some exciting news. I've made a little breakthrough and figured out the exact location of our issue. It appears to be with the delayed allocations in the shield /...