I'll try playing around with some of those profiling tools when I have some more time, maybe this weekend. In the meantime, I'm not super sure whether this is an issue that affects non-threaded async things.
Note: The following observations will be based on [this file](https://git.termer.net/termer/KommandKit/src/branch/master/tests/benchmark.nim) which I've been using to test out performance of my currently-minimal framework. I get pretty high memory usage with a single thread that seems to grow linearly, but it's hard to tell when only using a single thread because there is less capacity for serving requests, and therefore less chance for leaks. It _seems_ to grow linearly, and I don't have any cross-thread data except for a single object allocated with `createShared` which isn't interacted with at all during the program's life, other than at its construction. What I tend to notice is that after slamming the server with huge numbers of connections, the memory from the previous attack is never freed, and more memory is allocated on top of it. Manually calling the cycle collector periodically tends to help the situation, but it never goes down much, and continues allocating more each session. This can be observed on a single thread, although it's less pronounced than say, 12 threads. If you're curious, you can clone the repo and try `benchmark.nim` yourself with the flags documented at the beginning of the file. You can control the thread count (or use 0 for all threads, -1 for all threads minus one, etc), add dummy routes/middleware, etc. I tried to be fairly thorough. Testing now, after 5 minutes, memory went from 30MiB initially with 5k connections to now 52MiB+, and it never goes down to a consistent point, always climbing higher, regardless of running `GC_runOrc`.
