Does Parameter Order Make A Difference

Does Parameter Order Make A Difference?

I remember reading once that frequently accessed method variables placed first within a method’s signature are accessed faster as they are allocated for available cpu registers.

 

As I was refactoring C# code in a financial application that required every little nano-second micro-optimized, I noticed a few functions and methods that had parameters seemingly accessed the most, placed last in their signature.

 

That’s where this Curious Consultant started wondering… does parameter order make a difference in function and method signatures in C#? What would happen if the parameters in the signature were re-ordered?

 

Let’s find out!

 

Constructing the Test

For this test, we needed to create 3 methods:

  • a parent method that would call two other methods with the same signature, but different names
  • a child method 1 that tests the first 2 parameters being called in a loop
  • a child method 2 that tests the last 2 parameters being called in a loop

 

The trick here though is to ensure an actual difference was registered (ha! no pun intended! 🙂 ) at compile time:

  • when testing child method 1, I had all the code commented out that referenced child method 2
  • vice versa. When testing child method 2, the code was recompiled with all references to child method 1 commented out

 

The code is written in Visual Studio 2017 targeting .Net Framework version 4.7.1 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.

 

Assumptions:

 

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:

  • 250
  • 500
  • 5,000
  • 25,000

 

Locked and Loaded!

These tests were run a few times throughout the day.

 

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.

 

Additional caveat: only the last results are being shown here. All the previous results were similar. That is, the clear winner indicated below was the winner for every single test.

 

The Results:

In this test scenario, whenever the variables access the most were placed first in the method signature, that performed faster.

 

Number of Times Method Called

 

250

500

5,000

25,000

TestIfParameterOrderMakesADifferenceSub1

00:03.2695409

00:06.5599658

01:03.1584980

05:17.8328597

TestIfParameterOrderMakesADifferenceSub2

00:04.1061960

00:08.1929888

01:19.8485032

06:45.5268578

Delta (rounded):

00:00.8366

00:01.6330

00:16.6901

01:27.6940

 

In Summary:

Does parameter order make a difference? In C#, it’s quite evident from the results that placing the variables utilized the most first in a method’s signature does increase performance.

 

As the number of times the child method was called increased, the difference between the two became more and more readily apparent. The difference in execution times, despite doing almost the exact same thing, was nearly 90 seconds for 25,000 calls. In the computing world where processors are running at super-high frequencies, that’s HUGE. If the methods are in a real-time financial application, intense computer game, or where instant results matters most, any programmer should definitely reconsider refactoring their method calls and signatures.

 

In the more practical world, taking into account at the top end of the test the methods were called 25,000 times, which does nothing but loop 10,000,000 times, the speed difference will probably be negligible to the end user. In fact, they’ll probably blame it on their computer’s internet connection or their operating system’s lack of responsiveness.

 

As for this Curious Consultant, I’ll be making a conscious effort henceforth to make sure parameter order is lined up with the most used first, so I can deflect the finger pointing performance issues as appropriate. 🙂

 

The Code:

 

David Lozinski