Why is Math.max so expensive in Java?

Question

I want to do the following

int sum = x+y;
sum = Math.max(sum,x);

but that line of code tends to take longer than

int sum = x+y;
if(x>sum)sum=x;

I hope this is not inappropriate to ask, but can someone explain why this is?

I already looked in the source code and all Java is doing is

return (a >= b) ? a : b;

score 6 · Accepted Answer · edited May 07 '15 at 07:49

6

Maybe because Java's Math class is being created for the first time like any other Singleton or something like that, because no one used it before that, like class loader operation.

edited May 07 '15 at 07:49

Maroun

94,125
30
188
241

answered May 02 '15 at 14:54

roeygol

4,908
9
51
88

OP: for this reason, to get better accuracy in such performance comparisons, it's recommended to read [How to write micro benchmarks](http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java). – RealSkeptic May 02 '15 at 15:14
1

Whoa. Why is this an accepted answer? Okay, please elaborate: is it "slower" when you call `Math.max` the second time around? – Aleksey Shipilev May 02 '15 at 18:18

score 3 · Answer 2 · answered May 02 '15 at 14:55

Method calls aren't free (even ignoring the potential class load that Roey pointed out): They involve pushing the arguments and a return address on the stack, jumping to a different location in the code, popping the arguments off the stack, doing the work, pushing the result on the stack, jumping back, and popping the result off the stack.

However, I suspect you'd find that if you had a Math.max call in a hotspot in your code (a place that was run a LOT), Oracle's JVM's JIT would optimize it into an inline operation to speed it up. It won't bother if there doesn't seem to be any need, preferring speed of compilation of bytecode to machine code over optimization; but it's a two-stage compiler, where the second stage kicks in to more aggressively optimize hotspots it detects in the code.

@KatedralPillon: That alone won't make it a hotspot. The JVM is fairly smart about optimizing when it will really pay off and not bothering when it won't. — T.J. Crowder, May 02 '15 at 16:30

score 0 · Answer 3 · edited May 23 '17 at 12:14

microbenchmarking in Java is a very hard job in general. The example and statement cannot be generalized and as usual, the answer to your question is "it depends". ;). First of all, the source code in you see in the JDK implementation for Math.max is a default, which is not used at all on modern hardware. The compiler replaces this call with a CPU operation. Read more here.

This of course does not answer your question why your code is 'faster' now. Probably, it was not executed at all, because of dead code elimination, a compiler feature. Can you give us some surrounding code? Details about how often it is called is useful as well. Details about hardware also. Very important as well: Disable all power save features and all background tasks if you do 'measurements'. Best is to use something like JMH Cheers Benni

Why is Math.max so expensive in Java?

3 Answers3