8

What is the best way to loop through an array when you need the index?

Option 1:

int len = array.length;
for (int i = 0; i < len; ++i) {
    array[i] = foo(i);
}

Option 2:

for (int i = 0; i < array.length; i++) {
    array[i] = foo(i);
}

Or, does it not matter? Or is there a better way to do it? Just to point out the differences: In one case, the length of the array is evaluated as part of the test in the loop, although the compiler should normally optimize that.

Secondly, is ++i any different here from i++? I definitely prefer ++i if it is C++ but am not sure for Java.

Improve this question
1
  • 3
    These shouldn’t be any different. Commented Sep 29, 2012 at 2:41

4 Answers 4

Reset to default
6

i++ vs ++i does not matter in this particular case. While C masters will tell you to store array.length in a variable, modern optimizing compilers make that unnecessary in this case as long as the length does not change in the loop. If you're really concerned you can benchmark both, but since .length doesn't actually need to traverse the entire array each time you'll be OK.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Great answer! Actually it's also recommended to always use option 1, isn't it?
Option 1 to which question? To i++ vs ++i? I prefer i++ for readability reasons, but I can see why ++i might be a better default, so that the new value of i is used in case you happen to change your code and don't notice the postincrement. ++i is also faster for stupid compilers which don't realize that the user doesn't care what value the expression has.
No, I mean option 1 for .length. For ++i vs. i++, I think it's only a code style issue.
If all compilers will do the optimization, it's only a stylistic question anyway. I still feel like option 1 shows that the coder cares about performance, but I guess one could also argue that it shows that you don't realize that the Java compiler takes care of the optimization for you.
6

Generally those two methods are equivalent. You should note that in 

for (int i = 0 ; i < foo() ; i++) {
    ...
}

the foo() is called once before each iteration (as opposed to only once before the first iteration), so you might want to take this into account for more complicated situations by perhaps doing something like

int n = foo();
for (int i = 0 ; i < n ; i++) {
    ...
}

which is analogous to your Option 1. So I would say Option 1 is certainly the safer of the two, but most of the time it should not make a significant difference which you use.

As for your second question: ++i first increments your variable and then retrieves it's value, i++ first retrieves the value and then increments. Just try these two pieces of code:

int i = 0;
System.out.println(++i);
------------------------
int i = 0;
System.out.println(i++);

The first prints 1 but the second prints 0. Of course when ++i and i++ are alone it makes no difference.

Improve this answer

3 Comments

I don't see i < foo() in the question. Has it been updated? :)
@BheshGurung That foo function demonstrates how the rhs of for-loop conditions are evaluated repetitively, as I mentioned. When you have something like array.length on the rhs, it will make no difference. But when you have something like foo, you should exercise caution to some degree.
@arshajii I was worried that foo() in the case of size() access would slow down things and I ran some test (see last answer). Apparently it's the same. Does the compiler just transform size() to a simple var access at compile time ?
0

for whether to use "array.length" in for loop: Generally the compiler will do some optimization, as a result it is equivalent to using a variable in the for loop

for "i++" and "++i" In C++, ++i is preferred and more efficient, but in Java, they are equivalent in this case.

Improve this answer

Comments

0

In addition to arshaji response I wanted to know if there was a performance benefit of using size() in a loop vs storing it in advance. I believe the result show that the compiler does optimize things and accessing the length of a list is the same as accessing a variable ( I was worried that the fact it had to go through a function would slow down things).

Here is the time it takes for those two for different method of loop:

for(long i = 0 ; i < mylist.size(); i++){}
VS
for(long i = 0 ; i < 10_000_000; i++){}

Here is the result for a list of ten million elems:

fixed length:
,162,157,151,157,156,159,157,149,150,170,158,153,152,158,151,151,156,156,151,153
getSize:
,164,156,159,154,151,160,162,152,154,152,151,149,168,156,152,150,157,150,156,157



import java.util.ArrayList;
import java.util.List;

public class Main {

    final static int LENGTH_SAMPLE = 20;
    final static long LENGTH = 10_000_000;

    public static void main(String[] args) {

        List<Long> mylist = new ArrayList<>();
        for(long i = 0 ; i < LENGTH; i++){
            mylist.add(i);
        }
        System.out.println("fixed length:");
        for(int i = 0 ; i < LENGTH_SAMPLE; i++){
            System.out.printf("," + fixedSize(mylist));
        }
        System.out.println("");
        System.out.println("getSize:");
        for(int i = 0 ; i < LENGTH_SAMPLE; i++){
            System.out.printf("," + fctSize(mylist));
        }
    }

    private static long fixedSize(List list){
        long start = System.currentTimeMillis();

        for(long i = 0 ; i < LENGTH; i++){
            System.currentTimeMillis();
        }
        return System.currentTimeMillis() - start;
    }

    private static long fctSize(List list){
        long start = System.currentTimeMillis();

        for(long i = 0 ; i < list.size(); i++){
            System.currentTimeMillis();
        }
        return System.currentTimeMillis() - start;
    }
}
Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.