Noob. Chaining efficiency?


I am a C++ dev currently discovering Rust. I read a lot about the language and tinkered but I still have an issue with the chaining optimization.


Here I read that chaining multiple iterators is not -or may not be- as efficient as packing them in more specialized ones.

But, isn't the compiler able to spot what is happening with smaller and simpler blocks and convert it to very optimized code? It should be simpler for it.

I would be nice to have very simple blocks chained and be done with it, letting the compiler doing the hard work.


The compiler already does all the hard work, so what is your question? Sometimes it makes decisions based on heuristics that manage complex trade-offs. Maybe your chain won't be properly inlined and optimized as well as it could be as a result. Finding global minima is a hard problem.

1 Like


Yes I have no doubt the compiler is optimizing the code, it is just that having separate filter_map and others, made me wonder if the result would always be the same with filter and map separately for example.

My gut feel is that they'll have roughly the same performance characteristics, with some lambdas lending themselves to optimise better in one situation over another... but as always, don’t just listen to some random guy on the internet. If you care about performance then write a benchmark.

1 Like

You are right Michael, as I do in C++.
I have got the answers I needed.

Thanks :+1:

The main benefit of having filter_map is when the alternative is map, then filtering on something the map computed, then another map that's removing the information the filter needed β€” you use it where you might use if let in sequential code.

This could provide benefits by saving some intermediate steps in the functions you are providing by using one function that can do the work all at once, but it's not inherently an optimization β€” it can be useful that way, but it is also for writing tidy code.


I get it.
I will test the codes on godbolt and look at the resulting assembly for different compilers ( especially when gcc integration is stable)


Generally when using Iterator::chain, it's well known that using the for_each combinator instead of a for loop optimizes better because Chain::for_each is specialized to emit two loops instead of a single loop that checks which half it's in each time.


Great, thanks Alice!
So basically, once you embrace the functional side, you stick with it

No, not really. Alice was talking about one specific case. Sometimes, functional iterator chaining style is more readable, or more efficient. Sometimes, loops are. Don't try to shove every procedural algorithm through the same iterator-shaped hole.


Yeah, this is a .chain specific issue. There are lots of other iterator combinators where this does not apply at all.

1 Like

Ok I will need to experiment then..

But, still, it would be nice for the simplicity of the language if the compiler could consistently erase those corner cases. Multiple small blocks of logic are an opportunity to.

Time will tell I guess.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.