Heavily speculating but it's not unreasonable that the recording process impacts the game fps. Eg if you had 2 processes trying to max out your CPU it'd be less efficient than doing them one after the other because they're fighting for resources, doing context switching (losing cache etc).
Tangential but the slab concept is actually really neat, basically a userland allocator for a specific type, or a vector that gives you the key inserted at depending on how you prefer to think. https://docs.rs/slab/.
The parking lot concept is also really neat! The premise is that a program with lots of mutexes doesn't actually need to allocate lots of blocking queues, because the number of simultaneous waiters is bounded by the number of threads.
I don't think it's a coincidence that both of the examples here are actually quite reasonable as standalone crates. They're important abstractions, but just a little bit too niche to justify a place in the standard library. That said, I agree that learning what all these crates mean is daunting, and that finding ways to make that easier somehow would be valuable.
> just a little bit too niche to justify a place in the standard library
parking_lot has actually been considered for inclusion in libstd[0], as a better alternative to the native mutex implementation (parking_lot mutex are smaller, can be const-initialized, can be moved, and tend to perform better - all while not depending on external, non-rust code). The effort is currently on hold, but it's possible that it will resume in the future.
Thanks for point it out, after a quick glance it actually looks like something I want to learn more about. Takes the niceties from prisma.io schema tooling and bring it closer to postgres.
