a

for

loop is faster than a

forEach

expression right?

foreach

is often

inline

, and then it yields the same exact bytecode.

oh

forEach and for (e in list) both allocate an iterator

You lose the concurrentmodification safety then.

This question sounds like premature optimization to me. Even if those two were not identical in performance, I suggest that you use the most readable for you (and your team). Also, if you need to

break

or

continue

, use the

for

loop as it is not supported in

forEach

.

I agree on the early optimization aspect. (Importance is relative to the application) However it's one order of magnitude slower(in milliseconds). Not sure why

forEachIndexed

is not as inefficient though 🤔 https://try.kotlinlang.org/#/UserProjects/eeg4jaic5jrlb4utcb6269lsfh/kifrboelan2267bgrijt0lg6o5

That a terrible way to banchmark stuff on the JVM.

o.o

Yeah, that is true... I need to do a proper benchmark to verify 😅

Those margins 🤔 . I can't imagine any reason why indexed would be faster then normal.

I think that JMH removes such optimisations AFAIK

Allocating an iterator is always more costly than just using an index, and on Dalvik VM (Android 4.x), the cost usually results in significantly poorer performance, often dropping frames when done during animations or user interactions.

Dropping frames just from an iterator? That can't be right, surely there are hundreds of iterators created every second on Android, no? Also, Iterators are just small objects, I'm sure the VM can handle creating those?

@karelpeeters It is significant if done inside a draw method in a view for example. It runs 60 times per second (or 120 on faster displays). On a slow device it definitely noticeable.

Interesting, thanks!

Also, this applies to running things on the main thread (for the UI). On background threads we can be more lenient and I tend to go for more readability 😅

tho it make sense to optimize in onDraw method of course (which is still quite specific case), I don’t think that you will get dropping frames because of iterator instance creation, even 60 small objects per second shouldn’t cause any significant pressure on GC even on slow devices, most probably if you really do this in onDraw you have other expensive things

Enums are allocated once. Iterator are allocated on each iteration. Before ART (5.0+), it is known to cause a significant GC pressure, so it's not premature optimization, but just making a decent UX for users. Maybe when all apps are as smooth as real-life on all devices in use, I'll reconsider, but we're not there, so I keep optimizing for onDraw and other hot spots, and it's not making code any less readable thanks to inline higher order functions.

I think the issue with using

forEach

is not the iterator allocation but rather that each iteration it's making a function call to the closure lambda where as in a traditional for loop it doesn't. Again it can be an early optimization since it only has an effect if we have thousands of elements. It's something to be mindful about, but always better to optimise if we observe adverse effects. I always like to test apps on old and low power devices to make sure 😁

Yes, allocated on each iteration, I'm comparing with enums not because of type of allocation, but because of such sentences:

Known to cause a significant GC pressure

Sounds like a dogma than a real case. Again, I agree that it make sense to use loop with onDraw, but it's still very specific case and we usually care about it just because we know that you should be careful on such hot methods, but replacing iterator around your code base is exactly premature optimization

Well, it's not dogma or something, but just facts that not allocating is cheaper if you don't replace it with something more expensive. Also, allocating an iterator is useless for immutable lists, or lists that you're certain you don't modify concurrently. That's why Anko commons and Splitties collections have a forEachByIndex function that doesn't use an iterator. I don't care about the premature optimization dogma if you want my opinion. All I care about is use case, readability (maintainability) and efficiency.

@gildor I'll have to check the decompiled code again after the weekend. I'm sure it was making an invocation to the lambda 😅

Are you sure that you are not talking about forEach on sequence?

I'm sure I'm not talking about sequences yeah. Haven't look at them in this case as they are completely different

@pablisco I checked your benchmark and results make perfect sense.

forEachIndexed

is Kotlin stdlib function that create one more additional object with index and value, Louis above talked about own custom loop, implemented using iteration by index instead of iterator, not about this stdlib function Something like this:

inline fun <T> List<T>.forEachByIndex(block: (T) -> Unit) {
    for (i in 0 until size) {
        block(this[i])
    }
}

Here's the implementation where I check eagerly for size changes that may lead to out of bounds later on in the iteration (not as "safe" as iterator, but better than nothing to spot programmer errors): https://github.com/LouisCAD/Splitties/blob/61a4035ba3b18270dbfb0828436b5045bff44919/modules/collections/src/commonMain/kotlin/splitties/collections/Lists.kt

rip i started a discussion that may not be answerable x.x

@Smallville7123 in theory

for(in)

is exactly the same as

forEach

. In practice, like many things in our field, it depends 😅

Your original question was answered in the first few messages