Java call type performance

Question

I put together a microbenchmark that seemed to show that the following types of calls took roughly the same amount of time across many iterations after warmup.

static.method(arg);
static.finalAnonInnerClassInstance.apply(arg);
static.modifiedNonFinalAnonInnerClassInstance.apply(arg);

Has anyone found evidence that these different types of calls in the aggregate will have different performance characteristics? My findings are they don't, but I found that a little surprising (especially knowing the bytecode is quite different for at least the static call) so I want to find if others have any evidence either way.

If they indeed had the same exact performance, then that would mean there was no penalty to having that level of indirection in the modified non final case.

I know standard optimization advice would be: "write your code and profile" but I'm writing a framework code generation kind of thing so there is no specific code to profile, and the choice between static and non final is fairly important for both flexibility and possibly performance. I am using framework code in the microbenchmark which I why I can't include it here.

My test was run on Windows JDK 1.7.0_06.

This level of microbenchmarking is pretty much pointless. My guess is what you're seeing is the JIT inlining the call chains, as they're an obvious hotspot if they're in the middle of the benchmark loop. The reason why the advice is "write your code and profile" isn't laziness, it's because so many environmental factors affect performance that you're unlikely to gain any tangible benefit by microoptimising. The best way to replicate these environmental factors is to measure on a realistic dataset and hardware. — millimoose
– millimoose, Commented Nov 22, 2012 at 0:58
Function calls take few instructions at best. This only matters if all you're doing is calling functions (and they cannot be inlined). — John Dvorak
– John Dvorak, Commented Nov 22, 2012 at 0:59
Further to what @millimoose says.... The JVM will compile bytecode at run-time to machine code (via the Just In Time - JIT compiler). All future invocations of the code will be very fast. Well, fast compared with interpreting bytecode. — Muel
– Muel, Commented Nov 22, 2012 at 1:01
I'm afraid, I cannot figure out what those "calls" mean. (For a start, they are not valid Java.) Unless you show us the actual code, we can only guess what it is doing, and our explanations are then guesswork based on guesswork ... — Stephen C
– Stephen C, Commented Nov 22, 2012 at 1:24

irreputable · Accepted Answer · 2012-11-22 01:08:35Z

1

If you benchmark it in a tight loop, JVM would cache the instance, so there's no apparent difference.

If the code is executed in a real application,

if it's expected to be executed back-to-back very quickly, for example, String.length() used in for(int i=0; i<str.length(); i++){ short_code; }, JVM will optimize it, no worries.
if it's executed frequently enough, that the instance is mostly likely in CPU's L1 cache, the extra load of the instance is very fast; no worries.
otherwise, there is a non trivial overhead; but it's executed so infrequently, the overhead is almost impossible to detect among the overall cost of the application. no worries.

answered Nov 22, 2012 at 1:08

irreputable

45.6k9 gold badges70 silver badges94 bronze badges

Sign up to request clarification or add additional context in comments.

Collectives™ on Stack Overflow

Java call type performance

1 Answer 1

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Your Answer

Sign up or log in

Post as a guest

Related