LinuxQuestions.org - does java compiler optimize this ...

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - does java compiler optimize this ... (https://www.linuxquestions.org/questions/programming-9/does-java-compiler-optimize-this-463701/)

does java compiler optimize this ...

does java compiler optimize that "something.length" in the below code during compile time or runtime(possible??) ::

Code:

for (int i=0;i<something.length;i++) {



doSomething(something[i]);



}

or do i need to give a "substituting" variables(lacking of words) first ??

.

Maybe it is better to do :

Code:

final int len = something.length;

for (int i=0;i<len;i++) {

  doSomething(something[i]);

}

Compilers with optimisation would look to see if something.length get's modified in the block or any of the methods that are called within the block. If there is any chance that it would be modified then it would keep the code as it is, checking the value on each iteration, if on the other hand it knew that it was not going to be changed then it would try an optimise the code by keeping it in a register.

Although I don't know enough about the Java compiler to answer your question. I'm not convinced that mrcheeks solution would save any time, although if the condition was more complex then it might be a better approach.

thanks for the reply ... i'm just being confused by some when they say its better to do what mrcheeks is doing while some other(although they never say it) simply just leave it and even for nested blocks with their own "someother.length" , but this "someother.length" of the nested blocks couldnt be understood yet during compile time ... i donno ...

i think its better for me to give a variable first before i understand how the for loop actually works ...

.

Quote:

Originally Posted by mrcheeks

Maybe it is better to do :

Code:

final int len = something.length;

for (int i=0;i<len;i++) {

  doSomething(something[i]);

}

hmm. if something.length was a function instead of just an integer then it would save for you, but as it is i do not see that it is saving anything..

It is just the fact that

Code:

something.length

is computed all the time in the loop. It might not be a real optimization but it was the only thing I could suggest in the code.

As I see it the potential danger of using a variable is; if within the loop, the loop counter may change its value. It probably doesn't in this case, but I suspect the example was given as that, an example.

Changing the example as follows:

Code:

int listSize = ledger.length;

for (int i=0;i<listSize;i++)

{

  ledger.balance(i);

}



// Where balance() is defined as:

balance(int)

{

  if (endOfMonth)

  {

    addEOMDirectDebits();

  }

  total += getSubTotal();

}



// And addEOMDirectDebits() is defined as:

addEOMDirectDebits()

for (int i=0; i<ledger.myAccount().getEOMDDList().length(); i++)

{

  addDDtoLedger(i);

}

// The addDDtoLedger() method will now modify the size of the ledger and thus ledger.length

Sorry for the long example, but I believe that it demonstrated what I am getting at. Stepping through this code we see that if this is being run at the end of the month then the variable used in the original condition ledger.length can change, and even then it will only change if we have direct debits due at the end of the month.

Now consider this, you wrote the code before any banking wizard thought of direct debits as a means of reducing their administratve costs. They didn't exist. You substituted ledger.length with a variable for optimisation reasons.

Now direct debits have been introduced and the code needs to be modified, it is given to newbie coder to implement,(whilst I agree there may be issues with how I've implemented it here, I am after all a newbie coder)

I test my code, it works the items are added to the ledger, sign the code off and time to celebrate, job well done.

Unfortunately because the code all runs and a total is calculated from the original loop it will probably be accepted for several months before someone realises that not all the ledger entries are being totaled up.

Consider the second loop, it has the condition of

Code:

ledger.myAccount().getEOMDDList().length()

I would suggest that this could be optimised in the following way:

Code:

EOMDDList eomDDList = ledger.myAccount().getEOMDDList()

for (int i=0; i<eomDDList.length(); i++)

{

  addDDtoLedger(i);

}

It still has a method call in the loop but is able to remove two method calls and return the end of month Direct Debit List object. That isn't 100% safe but if the object changes within the loop then that is really bad coding, however when newbie coder does come along to implement the addEOYDirectDebit method inside the addDDtoLedger() method within an if endOfYear() condition then it shouldn't break the code.

Anyway I hope that helps, and for what it is worth; when you can leave the optimisation to the compiler

cheers,

graeme.

>> "is computed all the time in the loop"

kind of like what i need to know(or confirm ??) initially ...

and this brings me to graemef's ledger.myAccount().getEOMDDList().length()

does the conditioning really computes them everytime in a loop even if that something.length is a method call similar to graemef's assuming that it is also possible to do that in a loop ??

//thanks to all for being patient ...

.

The original post was talking about an array. Arrays have a fixed length, so you don't have to worry about it changing. But I doubt there is a performance difference between accessing "something.length", which is a member of the array object, and a variable.

For elegance, in Java 1.5, if "something" was an Foo[], you can do this:

Code:

for (Foo x : something) {



doSomething(x);



}

I also doubt there is any performance benefit to this.

Quote:

Originally Posted by spooon

The original post was talking about an array. Arrays have a fixed length, so you don't have to worry about it changing.

Agreed, I was thinking in a more general case where in a loop there may be side effects, if the loop does have a side effect that might alter the length then you need to be careful. Which is why (in general) understanding the logic and how it is being used is more important that trying to squeeze a slight optimisation gain.

graeme.

>> for (Foo x : something) {

its good for me to know theres a new "style"(lacking of word) in doing things but i prefer to remain as "procedural" as possible at this initial stage ...

so i guess that the compiler will just leave it as it is(without optimization) if it couldnt understand the condition during compile time ... and ... a for loop always computes the condition throughout it iteration if its a method call to get an integer value(or something) during runtime ...

i think by giving a variable value is good for me sometime ...

.

graemef & spooon hit what i was talking about. the length member is not calculated every time it is accessed, but rather is changed when the array size is set/changed, so there should be no difference btw using a local variable and the array member length, except for the side effects of a change in length, in which case the length is the safe way to go..

hmmm.. sounds like i just repeated alot of stuff that was already said... but im leaving it anyhow. :)