designing a query system
10 points by fanf
10 points by fanf
I am perpetually saddened by the fact that codebases are fundamentally limited by their historic design choices. The way a program is architected specializes it, and sets it down a path it cannot be shaken from easily. I keep seeing features and optimizations blocked by years-old decisions that never considered their possibility.
Big salute to anyone who's capable of worrying about this sort of thing, and also actually getting anything real done. I sure as heck can't.
I’m not going to implement this with Rust’s actual async mechanism, since I have some concerns about its performance. I’ve thought about some concrete types of tasks and what their async state is going to look like, and I’ve concluded that using async would not substantially cut down on boilerplate. A manual implementation would have less (memory and runtime) overhead.
I thought this was an interesting paragraph. In what way is std::future::Future itself not performant? When it comes to latency, the situation with the existing runtimes isn't ideal, but us / ns of tail latency hardly matter for a compiler. I'd be surprised if tokio was far away from the optimum in terms of throughput. Otherwise I don't see what the author means here. I would certainly enjoy reading an entire blog post about it, since this blog has been consistently of very high quality.
Not enough information to say one way or another, but a few possibilities:
tokio. It has pretty good latency characteristics in general, but maybe not as good as a thread-per-core runtime.Either way, I think you're directionally correct that it's an odd statement without further explanation.