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.
Conversation
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!
2
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
yes, that’s what I’m doing. It’s still 10x slower than my macros, even without boxing :(
1
Sounds like a super interesting case study! With futures I think you have to rely a bunch on inlining and monomorphization. With macros thats kind guaranteed.
1
Might be interesting to inspect the generated code and comparing. Perhaps LLVM is doing some neat stuff like autovectorization on you macro version, but not on the futures one, for example?
1
the macros based one is just generating a lot less code :)
1