«

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

Chris Berg wrote:

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

see
http://www.google.de/groups?threadm=...oglegroups.com

"Chris Berg" <> wrote in message
news:...
> 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 ...

--
Tim Ward
Brett Ward Limited - www.brettward.co.uk

On Tue, 7 Dec 2004 15:04:08 -0000, "Tim Ward" <>
wrote:

>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

Chris Berg wrote:
> 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/vmspe...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.

Chris Berg wrote:
> #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
}

--
Daniel Sjöblom
Remove _NOSPAM to reply by mail

"Daniel Sjöblom" <_NOSPAM> wrote in message
news:cp5t9c$1bfg$...
> Chris Berg wrote:
> > #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
> }
>
> --
> Daniel Sjöblom

How about this one
---
for(int i=0; i<100; i++) {
Int j = new Int(i);
}
---

On Wed, 08 Dec 2004 05:47:07 +0200, Daniel Sjöblom
<_NOSPAM> wrote:

>
>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

Chris Berg wrote:
>>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?

With the javap tool.

>>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.

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.

Chris Berg wrote:
>>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?

Use the javap tool that is provided with the SDK.

>>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.

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).

--
Daniel Sjöblom
Remove _NOSPAM to reply by mail