Does anyone have an argument for which for loops they prefer for efficiency reasons? I’ve read arguments against using iterators because they are an object that needs to be garbage collected, versus a traditional for loop.
I use regular for loops on my game and foreach at work, because that’s their standard.
You must have a fully developed game if you have time to worry about for loops. #programmerproblems
I personally use them how java begs you too. Foreach for collections. For for when I need the index.
GC is an issue that I think we should all be paying attention too, so coding with that in mind helps code in the future IMO. Just wondering on your thoughts 
Just use whichever one makes more sense to you in your context.
Also, you really shouldn’t be worrying about “efficiency” until you’ve actually measured your performance.
See also: https://stackoverflow.com/questions/385506/when-is-optimisation-premature
Yes I agree. I’m at the stage of making micro optimizations. Thought it would be an interesting discussion.
Yes it makes a difference. At least if you know the implementation of the list you want to iterate, you can chose the more efficient way. Take a look at the O notation talked about here https://stackoverflow.com/questions/2113216/which-is-more-efficient-a-for-each-loop-or-an-iterator
Additionally, the magic iterator object is somehow source of mystery. Normally, the iterator object should be created on the stack by the runtime, hence it’s gone after the return of the method and no GC involved. However, I (and many others) were able to take measurements where one could clearly see, that there is actually a lot of garbage created for this iterator…BUT: It’s possible that the circumstands of benchmarking and profiling just cause that the runtime doesn’t use stack allocation here. You can find several discussion over that on the internet, and I think even in this forum. That was the point where I gave up and switched to c loops for everything running in the production build of “my game”. Normally, I would say that one shouldn’t care about it, since the iterator is a very small, short-living object where the runtime is optimized for. But in a gameloop, running potentially up to douzens of thousands of times per second, the amount of garbage could be gigantic. So yes…premature optimization is the root of all evil, we all know
Or for short, attempting to profile it drastically changes the reality. As Kevin says use the one that looks nicest and simplest, and don’t trust what the profiler says.
Cas
There should be a good possibility the iterator is removed by escape analysis and so not be a GC concern. Premature optimization is bad, relying on profiling to tell you what’s happening can be worse - I refer you to this message from earlier this year where @spasi talks about this exact issue (and recommends JITWatch)
Of course, there’s another option with collections these days -
list.forEach(item -> {
// do something with item
});
That uses an internal for loop. Internal iteration has the potential to be faster than anything else.
Question: didn’t @Riven once publish a structure that optimized for contiguous memory for objects? “MappedObjects”? Was there a preferred iteration process involved? Is that approach still considered useful? At the time it came out, it was a bit over my skill set, and I wasn’t able to learn the lessons it provided.
I traditionally used For loops, but I recently came up with a good reason to prefer a custom iterator model.
The rendering style I use depends on drawing order to look right, given potentially overlapping
objects. For most boards, that is top to bottom, left to right. However, it you offer the “reverse”
view, you also have to reverse drawing order, which complicates the clean “for” loop a bit. Now
add the “rotate 90 degrees” and you also have to swap the x and y axis, which REALLY complicates
things. You can’t avoid all the details everywhere, but a “for loop” model gets very messy. Using
iterators leaves the apparent code very clean and hides the messy details in the guts of the iterator,
which you only have to write once.