Support the `vararg` calling convention in C#

[sharwell]

The Virtual Execution System defined in ECMA-335 defines a vararg calling convention for methods which is not accessible from C#. As mentioned by @jaredpar in issue #36, both of the following signatures incur memory allocations for the purpose of passing parameters, even if those parameters are value types:

WriteLine(params object[] args)
WriteLine(params IEnumerable<object> args)

For applications which are sensitive to memory allocations but still wish to provide API methods which take a variable number of arguments, I propose including the following feature in addition to the more "friendly" methods taking object[] or IEnumerable<object>.

WriteLine(params ArgIterator args)

A method containing a final params ArgIterator argument would be emitted using the vararg calling convention. Access to the arglist IL instruction is implicit via C# code which accesses this argument.

[mburbea]

Isn't varargs already available via the __arglist keyword? And unless I'm mistaken this method was much slower than taking a params object[] but probably more memory efficient.

[jaredpar]

Why have this as a separate issue? Performance and usability are related discussions. Having them as two separate issues is going to make the conversation harder, not easier.

[sharwell]

@mburbea Two things

1. I wasn't aware of that, so ✨ to you.
2. That doesn't really count as "being part of C#", since it's not mentioned at all in the language specification and therefore could differ in behavior between implementations.

[mburbea]

Yeah, it like __makeref and __reftype and __refvalue are part of a set of secret keywords in VS. I'm not sure if Mono, Roslyn or other compilers support them. Yeah, they are completely undocumented But my guess is that is how the secret overloads of Console.WriteLine and string.Concat were written. I'm assuming in managed C++ .net 1.1 there were some more efficient means of dealing with these varargs methods, but even they were pretty much deprecated and it has always been nearly impossible to find anything on this feature set of the CLR. I'm still annoyed there is no version of IlGenerator.Call that works with constructors with varargs.

[HaloFour]

The problem with __arglist is that it is painfully slow. But that is the official mechanism in .NET for supporting variable arguments. It really only exists for the purposes of supporting varargs methods via P/Invoke, e.g.:

[DllImport("user32.dll")]
static extern int wsprintf([Out] StringBuilder lpOut, string lpFmt, __arglist);

See also: System.ArgIterator

[mburbea]

Is it __arglist or the argiterator struct that are slow? I've never really seen anything conclusive on the matter. And I've read, though never seen that in C++ you apparently could avoid the iterator entirely.

[mikedn]

Access to an __arglist is complicated because it requires checks to ensure type safety. varargs functions get a hidden argument which is used to pass some sort of description of the arguments - count and types. ArgIterator has to parse that description and it does so via calls to runtime helpers, accessing a single argument from the list ends up being more expensive that reading an element from an array.

[sharwell]

@mikedn Suppose for example you have the following method:

int Sum(params int[] values)
{
  int sum = 0;
  for (int i = 0; i < values.Length; i++)
  {
    sum += values[i];
  }

  return sum;
}

Now suppose you want to implement the same method without requiring the creation of an array. I believe you could use this:

int Sum(params ArgIterator values)
{
  int sum = 0;
  int count = values.GetRemainingCount();
  for (int i = 0; i < count; i++)
  {
    sum += __refvalue(values.GetNextArg(), int);
  }

  return sum;
}

I have not checked to determine at which point the second method is slower than the first.

[mikedn]

I believe the working version for the varargs looks like the following, at least that's what I tested:

static int Sum(__arglist) {
            var value = new ArgIterator(__arglist);
            var count = value.GetRemainingCount();
            var sum = 0;
            for (int i = 0; i < count; i++)
                sum += __refvalue(value.GetNextArg(), int);
            return sum;
}

1,000,000 Sum(__arglist(1, 2, 3)) calls take 288ms on my machine.

Can you guess how much time the params int[] version takes?

It takes 10ms. No comment 😄

[tmat]

Yes, __arglist is legacy, not-optimized and shall not be used. It's also not portable.

[mburbea]

I just tested and the slow part seems to be the ArgIterator. Calling a method with __arglist on its own is actually pretty fast Instantiating the iterator is horribly slow. They seem to be calling some native code on instantiating that does all the handling. Unfortunately, C# is extremely cautious about letting you mess with the RuntimeArgumentHandle. C# won't let you box or turn it to a valuetype. I imagine if you can extract the pointer you might be able to parse arguments if you know what your doing in a wildly unsafe manner. I suppose with some IL you might be able to pull it off but C# isn't convinced that you can write a delegate that takes an Arglist. Edit: You can write a delegate that takes a RuntimeArgumentHandle. It can't be generic either as they can't be boxed and thus can't be used as a generic arg.
Here is a method to get the PointerValue if anyone wants to play...

public delegate IntPtr GetPtrType(RuntimeArgumentHandle a);
public GetPtrType GetPtr = new Func<GetPtrType>(()=>{
var dynamicMethod = new DynamicMethod("name", typeof(IntPtr),
                new[]{typeof(RuntimeArgumentHandle)}, true);
            var ilgen = dynamicMethod.GetILGenerator();
            ilgen.Emit(OpCodes.Ldarga_S, 0);
            ilgen.Emit(OpCodes.Call,
                typeof(RuntimeArgumentHandle).GetMethod("get_Value", BindingFlags.NonPublic | BindingFlags.Instance));
            ilgen.Emit(OpCodes.Ret);
            var func = dynamicMethod.CreateDelegate(typeof(GetPtrType)) as GetPtrType;
            return func;
}.Invoke();

I'm not sure what you can do with it but maybe somebody can write some unsafe code to parse out values.

Usage

static IntPtr GetThePtr(__arglist){
     GetPtr(__arglist);
   }

[mikedn]

Yes, the call itself is fast, the arguments are simply pushed on the stack like any other call arguments. The problem is extracting the arguments from the list, that requires parsing the signature used at the callsite and that's done via calls to runtime helper functions.

Getting the pointer won't help, you need to know the format of that signature. In general, any attempt at extracting the arguments from the pointer is a recipe for disaster.