A little optimization question: Local var allocation

[Chris Berg]

I often wonder: Does it make any difference in EXECUTION TIME which
version I choose:

#1:
String st;
while (true){
st=dis.readLine();
if (st==null) break;
< do something else >
}


#2:
while (true){
String st=dis.readLine();
if (st==null) break;
< do something else >
}

It's obvious that st is valid outside the loop in #1. But does it get
allocated on the stack for every iteration in #2, or just re-used? If
not, I suppose #2 is preferred as far as limiting the scope, enabling
gc, is an issue.

Chris

 

[Michael Borgwardt]

I often wonder: Does it make any difference in EXECUTION TIME which
version I choose:

see
http://www.google.de/groups?threadm=1101305706.051713.46060@z14g2000cwz.googlegroups.com

 

[Tim Ward]

I often wonder: Does it make any difference in EXECUTION TIME which
version I choose:

I'm sure a few seconds with Google would have found some of the other 137
times this has been asked and answered here in the last few months ...

 

[Chris Berg]

I'm sure a few seconds with Google would have found some of the other 137
times this has been asked and answered here in the last few months ...

Maybe not. Googling returns a heap of different discussions about the
subject, and not a very clear conclusion.

So, I will try to re-state the question:

Does a method create a stack frame for ALL local var's at the
beginning, or does it increment/decrement a stack pointer along the
way, thus re-using stack space?

A simple question with a binary answer, I suppose. Or?

Chris

 

[Michael Borgwardt]

Maybe not. Googling returns a heap of different discussions about the
subject, and not a very clear conclusion.

That is hard to believe, since the issue is very clear.
But admittedly, I don't think finding the right search terms for this
is easy.

So, I will try to re-state the question:

Does a method create a stack frame for ALL local var's at the
beginning,

On the bytecode level (which is all that matters) the JVM is
mandated by the specification to do it that way.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html#17257

A simple question with a binary answer, I suppose. Or?

Exactly. Which is why I find it hard to believe that there are
discussions about it that don't reach a clear conclusion, at
least not on a forum, such as this, where there are competent
people.

 

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

#1:
String st;
while (true){
st=dis.readLine();
if (st==null) break;
< do something else >
}


#2:
while (true){
String st=dis.readLine();
if (st==null) break;
< do something else >
}

In this case the two approaches compile to identical bytecode (which you
could have verified yourself), so there is not much to discuss. Even if
they didn't, worrying about this kind of microoptimization is utterly
futile. A better improvement to #1, #2 would be a more readable version:

String str;
while ((str = dis.readLine()) != null)
{
... something
}

 

[Ann]

In this case the two approaches compile to identical bytecode (which you
could have verified yourself), so there is not much to discuss. Even if
they didn't, worrying about this kind of microoptimization is utterly
futile. A better improvement to #1, #2 would be a more readable version:

String str;
while ((str = dis.readLine()) != null)
{
... something
}

How about this one

 

[Chris Berg]

In this case the two approaches compile to identical bytecode (which you
could have verified yourself), so there is not much to discuss. Even if

How do I verify that?

they didn't, worrying about this kind of microoptimization is utterly
futile. A better improvement to #1, #2 would be a more readable version:

String str;
while ((str = dis.readLine()) != null)
{
... something
}

This is your own taste. Personally, I don't like concatenations like
that; a program does not necessarily get more readable by reducing the
number of characters or lines. I usualy stick to the principle of one
thing happening on each line. But if you prefer it like that, fine.
Just modify "A better improvement..." to "I think a better
improvement..."

Unless, of course, if your version actually runs faster? It appears to
have one less reference to the string than mine !!

Chris

 

[Michael Borgwardt]

How do I verify that?

With the javap tool.

This is your own taste. Personally, I don't like concatenations like
that; a program does not necessarily get more readable by reducing the
number of characters or lines.

It's a well-known idiom that most programmers will recognize.

Unless, of course, if your version actually runs faster?

Again: you should NOT change code to something less clear because of
some microoptimazion. But I don't think it's any faster either.

 

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

How do I verify that?

Use the javap tool that is provided with the SDK.

This is your own taste. Personally, I don't like concatenations like
that; a program does not necessarily get more readable by reducing the
number of characters or lines. I usualy stick to the principle of one
thing happening on each line.

As Michael said, this is an idiom recognized by most programmers. I
don't think you will find many people advocating your approach, but as
always YMMV.

Unless, of course, if your version actually runs faster? It appears to
have one less reference to the string than mine !!

As I said above, you should avoid this kind of optimization. Any speed
benefit/disadvantage from my version (or anything comparable) is
absolutely dwarfed by the amount of time it takes to call the
DataInputStream.readLine method and do whatever work there is to be done
inside the loop.

But since you asked for it, the bytecodes are not equivalent, but that
doesn't really mean anything. On the current Sun VM both approaches will
be compiled to the same machine code by the JIT compiler (verified with
-server, not sure about client vm, but I don't expect much of a difference).