Variable number of arguments without boxing the value-types?

Question

public void DoSomething(params object[] args)
{
    // ...
}

The problem with the above signature is that every value-type that will be passed to that method will be boxed implicitly, and this is serious performance issue for me.

Is there a way to declear a method that accepts variable number of arguments without boxing the value-types?

Thanks.

Answer 1

You can use generics:

public void DoSomething<T>(params T[] args)
{
}

However, this will only allow a single type of ValueType to be specified. If you need to mix or match value types, you'll have to allow boxing to occur, as you're doing now, or provide specific overloads for different numbers of parameters.

---

Edit: If you need more than one type of parameter, you can use overloads to accomplish this, to some degree.

public void DoSomething<T,U>(T arg1, params U[] args) {}
public void DoSomething<T,U>(T arg1, T arg2, params U[] args) {}

Unfortunately, this requires multiple overloads to exist for your types.

Alternatively, you could pass in arrays directly:

public void DoSomething<T,U>(T[] args1, U[] args2) {}

You lose the nice compiler syntax, but then you can have any number of both parameters passed.

Answer 2

Not presently, no, and I haven't seen anything addressing the issue in the .NET 4 info that's been released.

If it's a huge performance problem for you, you might consider several overloads of commonly seen parameter lists.

I wonder, though: is it really a performance problem, or are you prematurely optimizing?

Answer 3

In C# 4.0 you can use named (and thus optional) parameters! More info on this blog post

Answer 4

Let's assume the code you're calling this method from is aware of argument types. If so, you can pack them into appropriate Tuple type from .NET 4, and pass its instance (Tuple is reference type) to such method as object (since there is no common base for all the Tuples).

The main problem here is that it isn't easy to process the arguments inside this method without boxing / unboxing, and likely, even without reflection. Try to think what must be done to extract, let's say, Nth argument without boxing. You'll end up with understanding you must either deal with dictionary lookup(s) there (involving either regular Dictionary<K,V> or internal dictionaries used by CLR), or with boxing. Obviously, dictionary lookups are much more costly.

I'm writing this because actually we developed a solution for very similar problem: we must be able to operate with our own Tuples without boxing - mainly, to compare and deserialize them (Tuples are used by database engine we develop, so performance of any basic operation is really essential in our case).

But:

• We end up with pretty complex solution. Take a look e.g. at TupleComparer.
• Effect of absence of boxing is actually not as good as we expected: each boxing / unboxing operation is replaced by a single array indexing and few virtual method calls, the cost of both ways is almost identical.

The only benefit of approach we developed is that we don't "flood" Gen0 by garbage, so Gen0 collections happen much more rarely. Since Gen0 collection cost is proportional to the space allocated by "live" objects and to their count, this brings noticeable advantage, if other allocations intermix with (or simply happen during) the execution of algorithm we try to optimize by this way.

Results: after this optimization our synthetic tests were showing from 0% to 200-300% performance increase; on the other hand, simple performance test of the database engine itself have shown much less impressive improvement (about 5-10%). A lot of time were wasted at above layers (there is a pretty complex ORM as well), but... Most likely that's what you'll really see after implementing similar stuff.

In short, I advise you to focus on something else. If it will be fully clear this is a major performance problem in your application, and there are no other good ways of resolving it, well, go ahead... Otherwise you're simply steeling from your customer or your own by doing premature optimization.