Code efficiency - declare variable sinside or outdie a loop.

[Ed Thompson]

I have long had the question of whether is is better to declare a
vraible inside a loop or outside a loop in Java.

To test I wrote the following code:

public class LoopTest {
public void inside() {
for(int i=0; i< 10;i++)
{
String x = "Edward";
}
}
public void outside() {
String x = null;
for(int i=0; i< 10;i++)
{
x = "Edward";
}
}
}

Which I disassembled using javap -c:

public void inside();
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 17
8: ldc #2; //String Edward
10: astore_2
11: iinc 1, 1
14: goto 2
17: return

public void outside();
Code:
0: aconst_null
1: astore_1
2: iconst_0
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpge 19
10: ldc #2; //String Edward
12: astore_1
13: iinc 2, 1
16: goto 4
19: return

If I read this right, it indicates that 'redelcaring' the variable
inside the loop is 2 opcodes shorter The first two opcodes in outside()
are not in inside()).

So now I have an interpretation issue. Does this really mean that
inside() is faster than outside()? Is one really more optimal?

Can someone help explain what is happening? (Not the line by line, but
what is java really doing?)

Thanx

 

[David Hilsee]

I have long had the question of whether is is better to declare a
vraible inside a loop or outside a loop in Java.

To test I wrote the following code:

public class LoopTest {
public void inside() {
for(int i=0; i< 10;i++)
{
String x = "Edward";
}
}
public void outside() {
String x = null;
for(int i=0; i< 10;i++)
{
x = "Edward";
}
}
}

Which I disassembled using javap -c:

public void inside();
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 17
8: ldc #2; //String Edward
10: astore_2
11: iinc 1, 1
14: goto 2
17: return

public void outside();
Code:
0: aconst_null
1: astore_1
2: iconst_0
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpge 19
10: ldc #2; //String Edward
12: astore_1
13: iinc 2, 1
16: goto 4
19: return

If I read this right, it indicates that 'redelcaring' the variable
inside the loop is 2 opcodes shorter The first two opcodes in outside()
are not in inside()).

So now I have an interpretation issue. Does this really mean that
inside() is faster than outside()? Is one really more optimal?

Can someone help explain what is happening? (Not the line by line, but
what is java really doing?)

Why not try measuring the performance at runtime instead of examining
opcodes? While it may the opcodes may be interesting, executing code will
probably provide a more straightforward answer about its efficiency.

 

[Dave Glasser]

So now I have an interpretation issue. Does this really mean that
inside() is faster than outside()? Is one really more optimal?

Whatever difference in speed there might be would be so infinitesimal
that it wouldn't be worth worrying about, IMO. I would always declare
the variable inside the loop since it's less bug prone than outside,
particularly if you're working with nested loops.

Besides, another compiler might optimize the code in such a way that
the the actual bytecode is identical for the two methods.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

I have long had the question of whether is is better to declare a
vraible inside a loop or outside a loop in Java.

To test I wrote the following code:

public class LoopTest {
public void inside() {
for(int i=0; i< 10;i++)
{
String x = "Edward";
}
}
public void outside() {
String x = null;
for(int i=0; i< 10;i++)
{
x = "Edward";
}
}
}

Which I disassembled using javap -c:

public void inside();
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 17
8: ldc #2; //String Edward
10: astore_2
11: iinc 1, 1
14: goto 2
17: return

public void outside();
Code:
0: aconst_null
1: astore_1
2: iconst_0
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpge 19
10: ldc #2; //String Edward
12: astore_1
13: iinc 2, 1
16: goto 4
19: return

If I read this right, it indicates that 'redelcaring' the variable
inside the loop is 2 opcodes shorter The first two opcodes in outside()
are not in inside()).

So now I have an interpretation issue. Does this really mean that
inside() is faster than outside()? Is one really more optimal?

Can someone help explain what is happening? (Not the line by line, but
what is java really doing?)

The only difference is aconst_null, astore_1 in the second version,
which can be removed by an optimizer anyway (in fact, the whole code can
be compressed to a single return.) Always declare variables in as
limited a scope as possible, unless you have a specific reason not to do
so.

 

[Liz]

I have long had the question of whether is is better to declare a
vraible inside a loop or outside a loop in Java.

To test I wrote the following code:

public class LoopTest {
public void inside() {
for(int i=0; i< 10;i++)
{
String x = "Edward";
}
}
public void outside() {
String x = null;
for(int i=0; i< 10;i++)
{
x = "Edward";
}
}
}

Which I disassembled using javap -c:

public void inside();
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 17
8: ldc #2; //String Edward
10: astore_2
11: iinc 1, 1
14: goto 2
17: return

public void outside();
Code:
0: aconst_null
1: astore_1
2: iconst_0
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpge 19
10: ldc #2; //String Edward
12: astore_1
13: iinc 2, 1
16: goto 4
19: return

If I read this right, it indicates that 'redelcaring' the variable
inside the loop is 2 opcodes shorter The first two opcodes in outside()
are not in inside()).

So now I have an interpretation issue. Does this really mean that
inside() is faster than outside()? Is one really more optimal?

Can someone help explain what is happening? (Not the line by line, but
what is java really doing?)

Thanx

You should measure, but my book on performance says that the first
4 variables inside a method (this includes the parameters) are faster
to access than the rest. And that local variables are faster
than fields.

 

[Chris Uppal]

public void outside() {
String x = null;
for(int i=0; i< 10;i++)
[...]

public void outside();
Code:
0: aconst_null
1: astore_1

The two methods result in /almost/ the same opcodes, the difference is that the
first two of outside() initialise the 'x' variable to null explicitly -- which
is just what your code in outside() asked for. Your code for inside() did not
ask for that extra step, and hence requires fewer instructions.

That extra operation could, I suppose, in sufficiently bizarre circumstances
make a measurable difference. Normally it won't make any difference at all
because:

a) it is tiny

b) it is /outside/ the innermost loop, and the innermost loop is normally where
most of the time is spent.

-- chris

 

[Ed Thompson]

Always declare variables in as limited a scope as possible, unless
you have a specific reason not to do

so.

MY concern was that inside the loop, a new Reference variable to
"Edward" would be created each time, while outside the loop the same
Refenece variable would be reused.

Was trying to avoid allocate/deallocate loop

 

[Roedy Green]

I have long had the question of whether is is better to declare a
vraible inside a loop or outside a loop in Java.

Declare a variable so that it has minimal scope to do the job. So, if
you can declare it inside the loop, this is better.

All local variables are allocated when you first enter a method, all
of them at once by incrementing the stack pointer, not where they
logically appear to be allocated, so there is no overhead for
"allocating" them over and over inside a loop.

 

[xarax]

you have a specific reason not to do

MY concern was that inside the loop, a new Reference variable to
"Edward" would be created each time, while outside the loop the same
Refenece variable would be reused.

Was trying to avoid allocate/deallocate loop

Totally wrong thinking.

The compiler will allocate stack frame slots according
to the entire method. When the method is called, the
entire stack frame is allocated at that time. While
the method is running, slots in the stack frame are
used according to the compiler's allocation.

Think of the stack frame as a machine array that
is indexed by integers. The variable "x" inside
the loop may have been assigned by the compiler
to stack frame slot 4. The slot already exists
when the method is entered. The code just stuffs
the datum into slot 4. stackframe[4] = <datum>.

It won't matter at all whether the variable is
declared inside or outside of the loop. Note that
you *are* assigning null to the outside variable,
so that code must be generated, even though stack
frame slots are initialized to null or zero.

 

[Ed Thompson]

Just the kind of perspective I was looking for, thanx!

 

[Ed Thompson]

All local variables are allocated when you first enter a method, all
of them at once by incrementing the stack pointer, not where they
logically appear to be allocated, so there is no overhead for
"allocating" them over and over inside a loop.

Thanx, I was looking for this kind of info!

 

[Roedy Green]

Thanx, I was looking for this kind of info!

Use javap to disassemble some of your code. You can then see what sort
of JVM byte codes it generates. If you read the JVM spec, all this
will come clear pretty quickly. If you are new to Java, but are an
experienced assembler programmer, I'd also recommend this approach to
help undersand oo by leveraging your low-level understanding.

JVM is a very easy assembler to learn.

 

[Chris Smith]

You should measure, but my book on performance says that the first
4 variables inside a method (this includes the parameters) are faster
to access than the rest.

Again, this says more about the suspect character of the book than about
performance. There are bytecodes designated to make code that
references the first four variables a lot shorter, but that doesn't mean
faster. What's faster will depend on the local processor architecture,
where there's not likely to be any special optimizations for any local
variable access.

And that local variables are faster than fields.

That one probably is true, because of cache locality issues. The local
stack is nearly always cached, so accesses take practically no time.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Liz]

Again, this says more about the suspect character of the book than about
performance. There are bytecodes designated to make code that
references the first four variables a lot shorter, but that doesn't mean
faster. What's faster will depend on the local processor architecture,
where there's not likely to be any special optimizations for any local
variable access.


That one probably is true, because of cache locality issues. The local
stack is nearly always cached, so accesses take practically no time.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation