• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is there a computation overhead on Array.length ?  RSS feed

 
Sajee Joseph
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,
Consider code A & B
Code A
=====
for(int i=0; i< myVector.size(); i++)
{
// some code
}
Code B
======
int j = myVector.size();
for(int i=0; i< j; i++)
{
// some code
}
It is well known that Code B is better than Code A (assuming that i dont add or delete elements to this Vector).
What i would like to know is whether the case is same for Arrays?
for example, is Code C better than Code D
Code C:
========
int j = myArray.length
for(int i=0; i< myArray.length; i++)
{
// some code
}
Code D
=========
for(int i=0; i< myArray.length; i++)
{
// some code
}
Thanks,
Sajee
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sajee Joseph:
It is well known that Code B is better than Code A.

Actually I strongly doubt that it is. Did you benchmark it?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36446
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sajee,
I think the compiler would optimize the difference away between A and B. However, I do think that B is clearer because it explicitly states the programmer's intention not to modify the vector.
There is no difference between C and D because "length" is just a field of the array. It's like accessing a variable.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The compiler can't optimize away the difference between B and A because it doesn't know for sure that myVector.size() will return a constant value. To do this, myVector would have to be a local reference to the Vector, and there would have to be no other references to it -- plus, of course, the compiler would have to understand the semantics of the Vector class. This is absolutely not the case. There might not be a big performance difference, but B is indeed better than A.
For C and D, the answer depends on whether myArray is a local variable or a member. If it's a local, then the compiler (the native code compiler, I mean now) can provably know that myArray.length is a constant, and the member access can be optimized away.

If it's a member variable, then the variable could actually be reassigned to point to another array, so the value of the variable has to be checked each time.
Now, actually, whether this statement is really true depends on whether there are any memory barriers in the loop. Under some circumstances, it's legal according to Java's memory model to execute the loop without checking that member variable. And if the variable is "volatile," then the answer is, again, different.
In any case, there are situations where C is better than D (with the typo fixed, of course; you mean i < j in the for-loop's condition, I expect.)
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Ernest on all points. For what it's worth, Joshua Bloch suggests this idiom for iterating over an array:

or RandomAccess list:

These are nearly equivalent in function to B and C. Added benefits though are that the for loops are shorter and they reduce the scope of the variable n. This has no performance benefit, but cuts down on the possibility of inadvertently reusing a variable name from a different loop. Which otherwise can create subtle and confusing errors. There's no need for n to be defined anywhere outside the loop, so keep it inside the loop. Just like i.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
The compiler can't optimize away the difference between B and A because it doesn't know for sure that myVector.size() will return a constant value.

But the Hotspot engine might well inline the method call, so that we have access of a local variable vs. access of a field.
There might not be a big performance difference, but B is indeed better than A.

Faster, possibly. With all due respect, I don't think that necessarily equates "better".
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:

Faster, possibly. With all due respect, I don't think that necessarily equates "better".

Agreed. But this is the Performance forum, in which "faster" is the whole point!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
Agreed. But this is the Performance forum, in which "faster" is the whole point!

Mhh, I'd rather think that "faster" never is the whole point, but that there always is a balance to take into account. Therefore I think that discussing the *costs* of performance optimizations is important in this forum, too.
Your mileage may vary, of course; no hard feelings!
 
Jonathan Locke
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course, now in J2SDK1.5, you would say:

and for an array, you would say the IDENTICAL thing:

and hotspot will take care of all those optimizations as required. nice huh?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jonathan Locke:
and hotspot will take care of all those optimizations as required. nice huh?

As far as I know, there is no special byte code generated for the for loop - so it will be javac taking care of producing the optimal byte code. Really nice though!
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!