Performance difference between forEach and map

Let us assume that I have a collection of Products. I want to iterate over them and duplicate its price.

For instance:

products.forEach {
    it.price = it.price * 2
}

I was asked to change forEach for map. So as to have the exact same code but use a map to iterate over the items since its more performant.

Can someone explain to me if and why is map faster than forEach? Also, in newer versions of Kotlin you can use a onEach iterator. Is this latter one even more performant?

Edit: when changing the forEach for a map, this is the end result:

products.map {
    it.price = it.price * 2
}

Let's look at what you're trying to achieve here.

By using forEach() (or, equivalently, a for loop) you're changing your collection in-place: you still have the same collection object, but its elements have been mutated.

Now, you could use map() to do the same, but that wouldn't be a good idea (no more efficient, and less clear to read), because while it does iterate through the elements, the point of map() is to create another collection from them.

The normal way to use map() would be along the lines of:

val newProducts = products.map{ Product(it.price * 2) }

(Obviously, this won't compile, because I don't know the proper name of your product object, nor what parameters its constructor might take. But I hope it gives an idea.)

What this does is to create a new collection, holding new elements derived from the original ones. You would then go on to use the new collection in the following code. (This may be what was intended when you were asked to use map().)

Doing it this way has advantages and disadvantages over updating the collection in-place. It takes more memory, to store the new collection and its new elements. But it works even if the original collection (and/or its elements) are immutable. It improves thread-safety; any other threads can continue to use the original collection without being affected by what you're doing, and you can then use your new one without the risk of other threads changing it. And immutable objects can be easier to reason about, and lead to fewer bugs.

This leads to a style of programming known as functional programming, which stresses immutability over mutable state, avoiding side-effects, and declaring the results you want rather than instructing how to get them. Kotlin adds many functional programming tools to the object-oriented paradigm it inherited from Java; as well as map(), functions like filter(), flatMap(), reduce(), associate(), along with function types, lambdas, and the easy use of immutability with val and the immutable List and Map types. This is a different way of thinking about programming, but it's well worth learning a bit about; while few people use Kotlin to write ‘pure’ functional programs, many of us are finding benefits from using some functional techniques.

(I'm not necessarily saying that it's worth using a functional approach in your particular case; we'd need to know a lot more context. But I hope you're now aware of the possibility!)