It's been said that rust futures "compile down to a state machine" like handrolled ones with mio. Is there any info on which design decisions led to this? Does it also apply when we Box stuff for dynamic dispatch? aturon.github.io/2016/09/07/fut
Conversation
There is this one by as well: aturon.github.io/blog/2016/08/1 (I was expecting the link you posted to be that one actually) - afaik, I don't think it holds when Box is in play, unless LLVM gets particularly aggressive.
1
The main relevant bit is under the heading "Zero cost?". I believe this was the first post where the futures library was announced - not sure if there is anything more recent. I believe talks were done at the time too.
1
Having to box to solve some type issues is pretty annoying. There are less of those since impl trait is there, but still
1
1
Yeah, doing some futures code right now while implementing a language server, and I do agree! It's getting better from what it was at least!
But yeah, sometimes boxing is actually good for performance, depending on where you do it. I haven't done any profiling of futures code though, so I don't really have any intuition for it.
My current issue is that I'm trying out the approach for a serialization lib, and creating the serializer is already slower than the whole serialization code I previously built out of macros
1
Yeah, it might be due to boxing. Might have to make some icky type aliases to get around it. Have you profiled it?
1
Show replies

