Andreas W

Hi I don't think you can do a trait like that, you can't have `impl FnMut() -> GeneratorResult` as a function return value :( I agree it would be nice...

> IMHO it should be possible, as I recalled from my memory rust's async function is just a sugar for `fn f(...) -> impl Future` An `async fn some_async()` is...

Yah I definitely think it's an interesting idea to split the cold and hot paths. Some experimentation and testing is necessary before committing to it though

Ah ok. I will try and think of something to try as well, but right now I don't have any clear idea.

Hi I'm not sold at the moment to be honest. This is IMO starting to get more complicated than the system already in place. Have you implemented any of the...

Thanks for the writeup! At the moment I won't pursue this split. I don't really see the benefit right now and I don't really have the time to do any...

Sounds like a good plan! I'm definitely interested in the approach.

Interesting! Looks like there were performance-regression for pretty much all benchmarks except for `chain_take_filter_map`? I wonder why that managed to improve while the others regressed by such hefty amounts?

> It seems benchmark test iterator_for_each_dedup_flatten_filter_map, iterator_next_basic_loop, generator_chain_take_filter_map and pushgen_iter_chain_take_filter_map are showing improvements, not just chain_take_filter_map. The first two are not using `pushgen` at all so shouldn't be impacted by...

> @AndWass How about also running the benchmark on your computer to confirm these benchmark tests are indeed showing improvements? I'll try and run them tonight.