First of all, there is a strong possibility that what you think you are seeing is actually due to a badly written benchmark. I strongly advise you to carefully read following Q&A and follow the advice therein:
Secondly, what you are saying doesn't correspond to my intuition. However, if the effect is real, one would need to do an in-depth analysis of the native code produced by the JIT compiler to understand the reason for the difference.
Finally, this smells of "premature optimization". As a general rule, the JIT compiler can do a better (more consistent, more reliable) job of optimizing than a human can. If there are simple optimizations like the one that you are trying, the JIT compiler will find them. Micro-optimization like this is generally a waste of (your) time.
So if you are going to try optimize, then you need to do it Scientifically.
- Get the application / library working first.
- Write a realistic benchmark for the code. One that matches how the code is likely to be used for real.
- Set yourself some measurable performance goals. ("As fast as possible" is not measurable).
- Run the benchmark to see if you already meet the goals. If yes, don't waste any further time on optimizing.
- Now run the benchmark using a performance profiler to identify the performance hot spots; i.e. the methods, etc that the application spends most of its time executing.
- Pick one hotspot, and look for possible ways to make it faster. Implement on possible optimization ... and run the benchmarks again to see if it improved things.
- Repeat steps 4 through 6 until you either meet the performance goal or run out of hotspots that can be optimized.