Yeah, it's a real problem. Basically anywhere I touch strings I get poor performance.
Unrelated to that, but I'd like to hear your thoughts (and anyone else's), what do you think of having HTTP server context instances be thread-local for multithreading purposes? You'd need to set up a server context instance per thread, but data being thread-local would be pretty clear. I've been burned in the past with shared data between threads, and I think the only real solution is to use an event bus to implement the actor model. Everything else seems to run the risk of segfaulting. I've been working on a web framework called KommandKit the past few days and right now I have a shared server context between threads, but the actual HTTP servers run per-thread. I've had some very confusing segfaults even with that, so I'm thinking I'll need to switch it over to being entirely thread-local. I was already planning on implementing an event bus similar to Vert.x's.
