Coroutines, Self-Referential Structs, and Pinning 228 Tip This example is located in this book's Git Hub repository in the ch09/c-coroutines-problem folder. With that, everything has been set up. Back to the optimization. Y ou see, new insights into the workload our runtime will handle in real life indicate that most futures will return Ready on the first poll. So, in theory, we can just poll the future we receive in block_on once and it will resolve immediately most of the time. Let's navigate to src/runtime/executor. rs and take a look at how we can take advantage of this by adding a few lines of code. If you navigate to our Executor::block_on function, you'll see that the first thing we do is spawn the future before we poll it. Spawning the future means that we allocate space for it in the heap and store the pointer to its location in a Hash Map variable. Since the future will most likely return Ready on the first poll, this is unnecessary work that could be avoided. Let's add this little optimization at the start of the block_on function to take advantage of this: pub fn block_on<F>(&mut self, future: F) where F: Future<Output = String> + 'static, { // ===== OPTIMIZATION, ASSUME READY let waker = self. get_waker(usize::MAX); let mut future = future; match future. poll(&waker) { Poll State::Not Ready => (), Poll State::Ready(_) => return, } // ===== END spawn(future); loop { ... Now, we simply poll the future immediately, and if the future resolves on the first poll, we return since we're all done. This way, we only spawn the future if it's something we need to wait on. Y es, this assumes we never reach usize::MAX for our IDs, but let's pretend this is only a proof of concept. Our Waker will be discarded and replaced by a new one if the future is spawned and polled again anyway, so that shouldn't be a problem.