C# Efficiency for method parameters

Question

Am I correct in saying that this:

public static void MethodName{bool first, bool second, bool third}
{
   //Do something
}

Is more efficient than this:

public static void MethodName{bool [] boolArray}
{
    bool first = boolArray[0]; 
    bool second = boolArray[1];
    bool third = boolArray[2];
    //Do something
}

My thoughts are that for both they would have to declare first, second and third - just in different places. But for the second one it has to add it into an array and then unpack it again.

Unless you declared the array like this:

MethodName(new[] { true, true, true });

In which case I am not sure which is faster?

I ask because I am thinking of using the second one but wanted to know if/what the implications are on performance.

In this case performance is not particularly important, but it would be helpful for me to clarify this point.

Also, the second one has the advantage that you can pass as many values as you like to it, and it is also easier to read I think?

The reason I am thinking of using this is because there are already about 30 parameters being passed into the method and I feel it is becoming confusing to keep adding more. All these bools are closely related so I thought it may make the code more manageable to package them up.

I am working on existing code and it is not in my project scope to spend time reworking the method to decrease the number of parameters that are passed into the method, but I thought it would be good practice to understand the implications of this change.

Answer 1

In terms of performance, there's just an answer for your question:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

In terms of productivity, parameters > arrays.

Side note

Everyone should know that that was said by Donald Knuth in 1974. More than 40 years after this statement, we still fall on premature optimization (or even pointless optimization) very often!

Further reading

I would take a look at this other Q&A on Software Engineering

Answer 2

Am I correct in saying that this: Is more efficient than this:

In isolation, yes. Unless the caller already has that array, in which case the second is the same or even (for larger argument types or more arguments) minutely faster.

I ask because I am thinking of using the second one but wanted to know if/what the implications are on performance.

Why are you thinking about the second one? If it is more natural at the point of the call then the reasons making it more natural are likely going to also have a performance impact that makes the second the better one in the wider context that outweighs this.

If you're starting off with three separate bools and you're wrapping them just to unwrap them again then I don't see what this offers in practice except for more typing.

So your reason for considering this at all is the more important thing here.

In this case performance is not particularly important

Then really don't worry about it. It's certainly known for hot-path code that hits params to offer overloads that take set numbers of individual parameters, but it really does only make a difference in hot paths. If you aren't in a hot path the lifetime saving of computing time of picking whichever of the two is indeed more efficient is unlikely to add up to the amount of time it took you to write your post here.

If you are in a hot path and really need to shave off every nanosecond you can because you're looping so much that it will add up to something real, then you have to measure. Isolated changes have non-isolated effects when it comes to performance, so it doesn't matter whether the people on the Internet tell you A is faster than B if the wider context means the code calling A is slower than B. Measure. Measurement number one is "can I even notice?", if the answer to that measurement is "no" then leave it alone and find somewhere where the performance impact is noticeable to optimise instead.

Write "natural" code to start with, before seeing if little tweaks can have a performance impact in the bits that are actually hurting you. This isn't just because of the importance of readability and so on, but also because:

1. The more "natural" code in a given language very often is the more efficient. Even if you think it can't be, it's more likely to benefit from some compiler optimisation behind the scenes.
2. The more "natural" code is a lot easier to tweak for performance when it is necessary than code doing a bunch of strange things.

Answer 3

Third way would be use of params, Params - MSDN

In the end I dont think it will change much in performance.

array[] though inheritates from abstract Array class which implements IEnumerable and IEnumerable<t> (ICloneable, IList, ICollection, IEnumerable, IStructuralComparable, IStructuralEquatable), this means objects are more blown up than three value type Parameters, which will make then slower obviously Array - MSDN

Answer 4

I don't think this would affect the performance of your app at all.

Personally

I'd go with the first option for two reasons:

1. Naming each parameter: if the project is a large scale project and there is a lot of coding or for possible future edits and enhancements.
2. Usability: if you are sending a list of similar parameters then you must use an array or a list, if it just a couple of parameters that happened to be of the same type then you should be sending them separately.

Answer 5

You could test performance differences on both, but I doubt there would be much difference.

You have to consider maintainability, is another programmer, or even yourself going to understand why you did it that way in a few weeks, or a few months time when it's time for review? Is it easily extended, can you pass different object types through to your method?

If your passing a collection of items, then certainly packing them into an array would be quicker than specifying a new parameter for each additional item?

If you have to, you can do it that way, but have you considered param array??

Why use the params keyword?

public static void MethodName{params bool [] boolAarray}
{
    //extract data here
}

Answer 6

Agreed with Matias' answer.

I also want to add that you need to add error checking, as you are passed an array, and nowhere is stated how many elements in your array you will receive. So you must first check that you have three elements in your array. This will balance the small perf gain that you may have earned.

Also, if you ever want to make this method available to other developers (as part of an API, public or private), intellisense will not help them at all in which parameters they're suppposed to set...

While using three parameters, you can do this :

///<summary>
///This method does something
///</summary>
///<param name="first">The first parameter</param>
///<param name="second">The second parameter</param>
///<param name="third">The third parameter</param>
public static void MethodName{bool first, bool second, bool third}
{
   //Do something
}

And it will be displayed nicely and helpfully to others...

Answer 7

I would take a different approach and use Flags;

public static void MethodName(int Flag) 
{ 
    if (Flag & FIRST) { } 
} 

Chances are the compiler will do its own optimizations;

Check http://rextester.com/QRFL3116 Added method from Jamiec comment

• M1 took 5ms
• M2 took 23ms
• M3 took 4ms