Alex Alex - 12 days ago 8
C# Question

C# Efficiency for method parameters

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

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.