Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > A little optimization question: Local var allocation

Reply
Thread Tools

A little optimization question: Local var allocation

 
 
Chris Berg
Guest
Posts: n/a
 
      12-07-2004
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
 
Reply With Quote
 
 
 
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-07-2004
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
 
Reply With Quote
 
 
 
 
Tim Ward
Guest
Posts: n/a
 
      12-07-2004
"Chris Berg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
Chris Berg
Guest
Posts: n/a
 
      12-07-2004
On Tue, 7 Dec 2004 15:04:08 -0000, "Tim Ward" <(E-Mail Removed)>
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

 
Reply With Quote
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-07-2004
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.
 
Reply With Quote
 
=?ISO-8859-1?Q?Daniel_Sj=F6blom?=
Guest
Posts: n/a
 
      12-08-2004
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
 
Reply With Quote
 
Ann
Guest
Posts: n/a
 
      12-08-2004

"Daniel Sj÷blom" <(E-Mail Removed)_NOSPAM> wrote in message
news:cp5t9c$1bfg$(E-Mail Removed)...
> 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);
}
---


 
Reply With Quote
 
Chris Berg
Guest
Posts: n/a
 
      12-08-2004
On Wed, 08 Dec 2004 05:47:07 +0200, Daniel Sj÷blom
<(E-Mail Removed)_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

 
Reply With Quote
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-08-2004
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.
 
Reply With Quote
 
=?ISO-8859-1?Q?Daniel_Sj=F6blom?=
Guest
Posts: n/a
 
      12-08-2004
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
1 little 2 little 3 little Kennedys dale Digital Photography 0 03-23-2008 01:03 PM
Difference between Session["var"] and Session("var") thomson ASP .Net 10 06-20-2005 01:02 PM
Difference between Session["var"] and Session("var") thomson ASP .Net 0 06-20-2005 10:54 AM
Threads.. Session var lost, App var ok Alvin Bruney ASP .Net 1 12-02-2003 01:56 AM
does "struct_name var = { 0 }; " fill var with 0? Fred C++ 3 08-10-2003 09:44 AM



Advertisments