Should I stop using local variables in Java?

No. The detail you're missing is where the optimisation happens.

In C-land, the application that reads in your source code (gcc for example) is the one that does most of the optimization (though more and more is done by the CPU itself, in its pipeline and microcode translation engines - not that there's a heck of a lot you can do to affect this as a programmer). Hence, it's that application (gcc) that has an -o (optimization level) option, and that is the application that potentially is going to churn through a ton of CPU cycles analysing your code to death.

In java-land, that is not how it works. javac is on rails: The spec decrees exactly what it should generate, pretty much down to the byte - in contrast to C-land where the spec is stacked to the gills with 'mays' and 'coulds' - compilers have a ton of leeway, notably including the bit width of your basic 'word', whereas java locks all of that down in spec, regardless of the bit-width of the CPU architecture you end up running on.

The optimization is done by java.exe - the runtime. And its approach is, as a rule, more efficient than C can ever be, because unlike C, the runtime gets the benefit of being able to check 'live behaviour', not something a C compiler can do (that's why C compilers tend to have a lot of 'hinting' systems, where you can inform the compiler about what you suspect the runtime behaviour is likely to be).

All modern JVMs work by running code inefficiently (that seemingly inefficient code that javac produced, which you notices with javap -v), and in fact run it even more inefficiently than that, as the JVM will add a bunch of hooks to add bookkeeping. For example, the JVM will track how often a method is invoked, how long it takes to run, and for example, for each if, counts of how often each branch is taken. All making it run even slower.

The JVM does this, because for 99% (literally) of all programs out there, about 99% (again, literally, not an exaggeration) of CPU/memory is 'spent' on less than 1% of the code, but the trick is, trying to predict which 1% that is. With all that bookkeeping, java will know, and will then analyse the bytecode of that 1%, and gets to use the runtime behaviour observed so far due to all that bookkeeping, to come up with fine-tuned machine code. This means java gets to write code that branch predicts (ensures the machine code does not have to jump around for most often taken branch path), except it's not a prediction: java.exe knows which one is the 'most often taken path'. Vs gcc which has to guess, optionally assisted by the programmer with branch hints in the source file.

That's just one of thousands of places where java.exe can apply machine code optimization.

That still means ~99% of the code runs very inefficiently. But, given that this takes less than 1% of CPU/memory, it just doesn't matter.

Java is slower than C due to various factors, but 'optimizing instructions' is not one of them:

• Java cannot use architecture-specific features that affect the underlying language model, such as 80-bit width variables in what used to be the coprocessor. Project Valhalla is trying to fix that.
• More generally java has a hard time interfacing directly with arch/OS-local low-level API.
• That bookkeeping, and the garbage collector, tend to have 'ramp up time'. They start off slow and become faster over time. Vs. C code which pretty much springs into existence running as fast as it ever will.

Naturally then, java is neither popular nor a good idea for simple command line one-off tools like ls or /bin/true. Java is fantastic at performance when writing, say, a web request responder. Those run for a long time and that hotspot process really helps there.