9

C# .Net: Fastest Way to check if a Number is Odd Or Even

Spread the love

C# .Net: Fastest Way to check if a Number is Odd Or Even

This will benchmark many techniques to determine in C# .Net: Fastest way to check if a number is odd or even.

There’s an amazing number of applications that do some sort of check if a number is odd or even. One of the most popular uses is to display results in alternating colors depending on whether it’s an odd or even row.

 

Probably the most popular way to do this is to use the modulus operator and code like the following:

But it’s a well known fact modulus is one of the slowest mathematical operators. Another common technique is to use the bitwise ampersand & operator because bitwise operations, generally speaking, are faaaaaaaaaaaast.

So that’s when this curious consultant started wondering in C# .Net: what is the fastest way to check if a number is odd or even? Is it the bitwise operand? Modulus? Using C#’s built in library function System.Math.DivRem (how many C# programmers even know about this?)? Or perhaps another, less common place, way?

 

The Set Up:

I wrote a C# Console application to test numerous techniques.

The code is written in Visual Studio 2013 targeting .Net Framework version 4.5 x64. The source code is available at the end of this blog so you can benchmark it on your own system if you wish.

In a nutshell, here are the methods:

#

Technique

Code Snippet

T1

Modulus %

T2

Bitwise Ampersand &

T3

System.Math.DivRem

T4

((x/2) * 2) == x

T5

((x >> 1) << 1) == x

T6

While loop countdown

T7

Last digit check

 

The code assumes all numbers are positive integers.

The exe file was installed and run on an Alienware M17X R3 running Windows 7 64-bit with 16 GB memory on an i7-2820QM processor.

The test was run for each technique over the following number of numbers:

  • 2,147,483,647
  • 214,748,364
  • 2,147,482
  • 21,474

Below 21,474, the difference in results were negligible. Well, at least on my machine. 🙂

 

Ready! Set! Go!

Before starting, my hypothesis was that I expected the bitwise ampersand & technique to be the fastest.

Let’s see what happened on my machine over multiple runs.

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

Winner marked in green; second place marked in yellow.

BENCHMARK RUN #1

@ 2,147,483,647

@ 214,748,364

@ 2,147,482

@ 21,474

T1: Modulus %

00:04.3742502

00.4230242

00:00.0040002

00.00

T2: Bitwise Ampersand &

00:04.8952800

00.4930282

00:00.0050003

00.00

T3: System.Math.DivRem

00:41.7713892

04.1292362

00:00.0400023

00.00

T4: ((x/2) * 2) == x

00:04.8892797

00.4880279

00:00.0040002

00.00

T5: ((x >> 1) << 1 == x

00:04.8272761

00.4780273

00:00.0050003

00.00

T6: While loop countdown

– too long –

– too long –

11:36.4118325

00.0690040

T7: Last digit check

03:43.5797880

21.3872233

00:00.1960112

00.0020001

 

BENCHMARK RUN #2

@ 2,147,483,647

@ 214,748,364

@ 2,147,482

@ 21,474

T1: Modulus %

00:04.4822564

00.4570261

00:00.0040002

00.00

T2: Bitwise Ampersand &

00:04.6942685

00.4920282

00:00.0050003

00.00

T3: System.Math.DivRem

00:41.8413932

04.2132410

00:00.0420024

00.0010000

T4: ((x/2) * 2) == x

00:05.1572950

00.4590262

00:00.0050003

00.00

T5: ((x >> 1) << 1 == x

00:04.8022747

00.4940283

00:00.0050003

00.00

T6: While loop countdown

– too long –

– too long –

11:41.7941403

00.0710041

T7: Last digit check

03:48.7550840

21.8652506

00:00.1980114

00.0020001

 

BENCHMARK RUN #3

@ 2,147,483,647

@ 214,748,364

@ 2,147,482

@ 21,474

T1: Modulus %

00:04.4072521

00.4270245

00:00.0050003

00.00

T2: Bitwise Ampersand &

00:04.9182813

00.4580262

00:00.0040002

00.00

T3: System.Math.DivRem

00:42.1004080

04.1962400

00:00.0420024

00.0010001

T4: ((x/2) * 2) == x

00:05.1442942

00.5140294

00:00.0050003

00.00

T5: ((x >> 1) << 1 == x

00:04.8032748

00.4980285

00:00.0050003

00.00

T6: While loop countdown

– too long –

– too long –

11:36.9518633

00.0700040

T7: Last digit check

03:46.1859370

21.7162421

00:00.1990114

00.0020001

 

Who would have expected?

The modulus operator, much to my surprise, performed the fastest. There was only one instance where it came second, and not by much. I was fully expecting the bitwise operation to surpass it, and am not really curious as to why the bitwise and operator is slower.

For second place, there appears to be no dominating technique. T4 using the ((x/2) * 2) == x technique performed just as well as T2 and T5 with their bitwise operations all the way up to 2 billion runs.

 

Should these results change your coding methods?

On my system, unless someone spots a flaw in my test code, and unless you have to check more than 2,147,482 numbers in one go, it really makes no significant performance difference which method is used for anywhere up to a few thousand conversions. Personally I’ll keep using the modulus operator because let’s face it: it’s easy to read, maintain, and understand what the coder is trying to do. It also performed the fastest on my machine.

Should you need to do a few hundred million checks, definitely keep using the modulus operator. After seeing my results, I don’t know why someone would use anything else unless you want to put in the code used for T5 with all its bit shifting to make it look like you’re doing some heavy-duty coding.

Obviously results may vary, and you should test on your system before micro-optimizing this functionality in your C# .Net application.

Hence why I’m giving you the code below. 🙂

 

The Code:

 


Spread the love

David Lozinski