A little optimization question: Local var allocation

Discussion in 'Java' started by Chris Berg, Dec 7, 2004.

  1. Chris Berg

    Chris Berg Guest

    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, Dec 7, 2004
    #1
    1. Advertising

  2. Michael Borgwardt, Dec 7, 2004
    #2
    1. Advertising

  3. Chris Berg

    Tim Ward Guest

    "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
    Tim Ward, Dec 7, 2004
    #3
  4. Chris Berg

    Chris Berg Guest

    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, Dec 7, 2004
    #4
  5. 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/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.
    Michael Borgwardt, Dec 7, 2004
    #5
  6. 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
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Dec 8, 2004
    #6
  7. Chris Berg

    Ann Guest

    "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);
    }
    ---
    Ann, Dec 8, 2004
    #7
  8. Chris Berg

    Chris Berg Guest

    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, Dec 8, 2004
    #8
  9. 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.
    Michael Borgwardt, Dec 8, 2004
    #9
  10. 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
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Dec 8, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alvin Bruney

    Threads.. Session var lost, App var ok

    Alvin Bruney, Dec 2, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    352
    rooster575
    Dec 2, 2003
  2. thomson
    Replies:
    10
    Views:
    2,482
    Eliyahu Goldin
    Jun 20, 2005
  3. thomson
    Replies:
    0
    Views:
    366
    thomson
    Jun 20, 2005
  4. Fred
    Replies:
    3
    Views:
    317
    Alf P. Steinbach
    Aug 10, 2003
  5. Ravikiran

    Zero Optimization and Sign Optimization???

    Ravikiran, Nov 17, 2008, in forum: C Programming
    Replies:
    22
    Views:
    845
    Thad Smith
    Nov 24, 2008
Loading...

Share This Page