Does adding local variables to methods make them slower?

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 computati开发者_运维问答ons 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.

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.

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.

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.

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.

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.