Math.Max/Min vs inline comparisons

Spread the love

Math.Max/Min vs inline comparisons

This test stemmed from my having to write a lot of code, and look at a lot of code, that was doing comparisons between 2-3 numbers finding the Max and Min between them and then performing some mathematical calculations.


Naturally, throughout the code there were a lot of Math.Max(a,b), Math.Min(y,z), and even some with triplet comparisons:

  • Math.Max(a,Math.Max(b,c))
  • Math.Min(x,Math.Min(y,z))

Performance wise, I figured it would be faster to do my own inline comparisons, but by how much?

That’s where this Curious Consultant started wondering… how much slower is a simple Math.Max and Math.Min vs inline comparisons?


Let’s benchmark it and find out!


Constructing the Test

For this test, it’s straight forward:

  • call a method with 3 ints and 3 doubles
  • compare the max/min on 2 ints each way and then 2 doubles each way
  • compare the max/min on 3 ints each way and then 3 doubles each way
  • keep a running total just to verify the results are the same the max’s/min’s are chosen correctly


The code is written in Visual Studio 2022 targeting .Net Framework version 4.8 x64, compiled in “Release” mode the build option “Optimize Code” checked. The source code is available at the end of this blog so you can benchmark it on your own system.


The exe file was run under Windows 10 Professional 64-bit with 32GB of memory.


The test was run with each child method called the following number of times:

  • 10,000
  • 1,000,000
  • 100,000,000


Ready to start!

These tests were run three times after a fresh boot with no other applications runrning to reduce the impact on the CPU. I’m only listing one of the result runs as they were all similar so I don’t feel a need to table-ize all 3.


All times are indicated in minutes.seconds.milliseconds format. Lower numbers indicate faster run time performance.


Winners are highlighted in green; there are no points for second place.


The Results of Math.Max/Min vs inline comparisons:

Test Run #1 (runs #2 and #3 had similar results)


Number of comparisons





Math.Max/Min w/ 2 ints




Inline w/ 2 ints





Math.Max/Min w/ 2 doubles




Inline w/ 2 doubles





Math.Max/Min w/ 3 ints




Inline w/ 3 ints





Math.Max/Min w/ 3 doubles




Inline w/ 3 doubles





In Summary:

Writing code inline is 99.9% of the time going to be faster than calling a static method. Thus, it’s no surprise in our Math.Max/Min vs inline comparisons that the static methods were slower.


What is amazing though is to see how much (significantly) faster it was to use our own inline comparison vs calling the static methods when comparing more than 2 double values. Even as the number of comparisons increased, the time ratio stayed about the same, which is 50%.


50% !!


Let that sink in.


Doing inline comparisons to find the highest value between 3 doubles is 50% faster than calling the static classes.


In practical terms, if you have one critical section of code that requires such a comparison, sure… write it once, be done with it, and rest assured that’s the fasted code going.


But if it has to be done in multiple locations?


Nobody is going to want to do this several times:

instead of this:

What a coding maintenance nightmare!


As for this Curious Consultant, when speed is needed, this Math.Max/Min vs inline comparisons has shown that doing our own inline comparisons will be the fastest way to go.


Otherwise, code will be written in such a way that easy maintenance can be done.


Until next time!



The Code:


Spread the love

David Lozinski