Does adding local variables to methods make them slower?

Question

This question has received a total of several paragraphs of answer. Here is the only sentence that actually tells me what I was looking for:

Your examples would make little difference since intermediate computations need to be stored temporarily on the stack so they can be used later on.

In fact, it answers my question perfectly and completely =)

Unlike all the cruft telling me "nooo don't ask that question". >_<

Like if you have a method, and you change it by increasing the number of local variables but make no other changes, does it make the method slower? Here's an example:

void makeWindow() {
    Display
        .getContext()
        .windowBuilder()
        .setSize(800, 600)
        .setBalloonAnimal(BalloonAnimal.ELDER_GOD.withColor(PUCE))
        .build();
}

or

void makeWindow() {
    DisplayContext dc = Display.getContext();
    WindowBuilder wb = db.windowBuilder();
    BalloonAnimal god = BalloonAnimal.ELDER_GOD;
    BalloonAnimal puceGod = god.withColor(PUCE);
    wb.setSize(800, 600).setBalloonAnimal(puceGod).build();
}

Another example:

int beAnExample(int quiche) {
    return areGlobalsEvil?
        quiche * TAU/5:
        highway(quiche, Globals.frenchFrenchRevolution);
}

or

int beAnExample(int quiche) {
    if (areGlobalsEvil) {
        int to5 = TAU/5;
        int result = quiche * to5;
        return result;
    } else {
        Game french = Globals.frenchFrenchRevolution;
        int result = highway(quiche, french);
        return result;
    }
}

Really, what I'm asking is: Is the number of this sort of local variable even relevant by the time the method's compiled to bytecode? If so, what about once Hotspot gets to work on it?

This question is relevant to the code generator I'm working on.

Smells like premature optimization -- see http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize — Jim Garrison, Apr 23 '11 at 04:09
probably no significant difference (especially if no obj creation occurs). might be interesting to try measuring to see. — seand, Apr 23 '11 at 04:14
@Jim ugh, I wish I could downvote comments. Did you even read the bold text? — amara, Apr 23 '11 at 04:30

score 5 · Accepted Answer · answered Apr 23 '11 at 04:20

5

The easy answer is no. Local variables consume runtime stack space. Allocating space for them only marginally increases the number of instructions. Your examples would make little difference since intermediate computations need to be stored temporarily on the stack so they can be used later on. Focus more on the readability of your programs rather than needless micro-optimizations.

If you're interested in looking at the actual bytecode of a class, investigate the javap program.

answered Apr 23 '11 at 04:20

Edawg

258
1
4

1

Thanks, this actually answers my question =) – amara Apr 23 '11 at 04:28
If you download the debug OpenJDK, you can get it to dump the native code it generates. – Peter Lawrey Apr 23 '11 at 08:34

score 1 · Answer 2 · answered Apr 23 '11 at 04:17

1

Don't worry about it. The compiler can do all sorts of crazy, make-your-head-asplode optimizations. Start with code that's correct and maintainable. Programmer time is worth far more than processor tiem.

answered Apr 23 '11 at 04:17

Matt Ball

354,903
100
647
710

I saw that text the first time. What do local variables have to do it? – Matt Ball Apr 23 '11 at 04:28
The output of a code generator doesn't need to be maintainable. In fact, with this one, nobody ever even sees it; it gets sent to javac directly. – amara Apr 23 '11 at 04:29

score 1 · Answer 3 · answered Apr 23 '11 at 04:17

1

Test it by running each method 1,000,000 times and divide the total time to calculate the cost per execution. In all likelihood, it won't be noticable.

Actually, Java compilers may even be smart enough to just compile it out.

Write your code for readability to reduce long term cost of maintenance. Then tune it in the 5% of places where you really need to.

answered Apr 23 '11 at 04:17

squawknull

5,131
2
17
27

@Matt: ooh, thanks! I wasn't doing a microbenchmark for this because I didn't think I could trust the results, but now I think I might. – amara Apr 23 '11 at 04:27

score 0 · Answer 4 · answered Apr 23 '11 at 04:58

The chances are that it will make little (if any) difference, and the "little" will be insignificant.

Focus on making your generator correct and maintainable, and let the Java compiler (particularly the JIT compiler) do the micro-optimization of the generated code.

Note that @Edawg's advice on looking at the bytecode is not necessarily helpful. The JIT compiler aggressively optimizes the native code that it generates from the bytecodes. It can be difficult to predict which of two bytecode sequences is going to be faster. Certainly, counting bytecodes, method calls and so on can be misleading.

The only way to be sure that you are generating "optimal" Java source code would be to compile it and benchmark it on your target platform. Even then, there's a good chance that your efforts at source-code level optimization will be negated ... by JIT compiler changes.

score -1 · Answer 5 · answered Apr 23 '11 at 04:57

-1

This is not a hotspot issue. There may need to be additional byte codes to load and store the local variables, but let the compiler worry about optimizing that.

You should concentrate on issues like null pointer checking in your generated code and how to report errors in a meaningful way that is tied to the source input that you are code generating from.

answered Apr 23 '11 at 04:57

ditkin

6,774
1
35
37

*sigh*... Thank you for the advice, but I *know* that stuff. I wish people would just answer the question... – amara Apr 23 '11 at 07:07

Does adding local variables to methods make them slower?

5 Answers5