性能受到打击吗？ 匿名类型的列表以实现类似此列表的功能 <int, string, …> （C＃中的多种类型的多维列表）

Question

I am wondering about whether or not creating a list of an anonymous type is the best way to effectively create a list of multiple types as well as its effect on general performance and efficiency. Mainly I just want to know if there is a more standard way of doing List?

Situation I every now and then find myself with a need to create a list that has multiple values each of a different type, List. Normally i would just resolve this with a Dictionary, but then there are the cases where i don't care about duplicated key values or need a 3rd (or rarely 4th) value. Usually this is for temporary list that just track something contained in a method like logging thrown errors and an associated value so that at the end of the method i can string together the messages for a log file or something.

What i have so far is this:

var list = new[] { new { RowNumber = 1, Message = "" } }.ToList();
list.Clear();//clears out the example used to create the anonymous type
list.Add(new { RowNumber = 10, Message = "bla bla" }); //adding to the list

I am debating on doing something like an extension or something to make this easier, but if the performance sucks or there is a better way, i would like to know.

Answer 1

I prefer to make a class. The IL just makes an anonymous class in native that gets called the same way as a normal class, so there is no performance hit associated with it. If you ever debug anonymous types, you'll notice the name has a long name like AnonymousTypes.Program+f__1

Creating a class improves the readability of your code IMO.

public class RowMessage
{
    public int RowNumber { get; set; }
    public string Message { get; set; }
}

You can also use Tuples, but even this is still unclear:

    public void MyMethod()
    {
        Tuple<int, string> myTuple = new Tuple<int, string>(1, "hi");
        List<Tuple<int, string>> myTupList = new List<Tuple<int, string>>();
        myTupList.Add(myTuple);
    }

Answer 2

I just experimented a little . Here's what I found:

• Anonymous types are as good as anything else. I can't really say "anything," since I didn't try everything. But I can tell you that they're as good as Tuple<> and concrete types. This is logical, because underneath the covers, the compiler actually builds types for anonymous types. In essence, at runtime, they are just concrete types.
• Your ToList call is redundant. This part's important. It's not super relevant to your immediate question, but looking at your example, you do new [] { ... }.ToList() . This forces a loop through the array after it's created. You'd be much better off using list initialization: new List<dynamic> { ... }; . That's what I used in my examples.

I ran tests 10,000 times each for:

• Anonymous type with array initializer (00:00:00.0050338 total)
• Anonymous type with list initializer (00:00:00.0035599 total)
• Tuple with list initializer (00:00:00.0025857 total)
• Concrete type with list initializer (00:00:00.0041538 total)

Running them again would just mix it up. The only consistent result was that arrays were, unsurprisingly, slower than going directly to a list.

---

If you're going to make an extension method, you'll probably want to go with one of the latter two options. Anonymous types don't travel well outside of their scope, as I'm sure you know. The choice is yours between concrete types and tuples. I'd go with concrete if you're using it a lot and/or outside of the original method, and a tuple if it just needs to exist somewhere. That's really a design choice that I can't make for you.

Answer 3

Since you are talking about enriching Exceptioninformation it is worth to mention that the Exceptionclass implements a property called Data which is of type IDictionary and can be used to append additional information.

    try
    {
        throw new FileNotFoundException{ Data ={ { "TEST", "Hello World" } } };
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Data["TEST"]);
        ...
        e.Data.Add("Whatever", DateTime.Now);
    }

If you find yourself adding the same information lots of times, consider some HelperMethods that add certain information to a giving exception. This could also take care for duplicated keys which use some sort of numeric postfix that increments like fileName_1 and so on, you get the idea. You can also create a standartized method of outputting those Information you provided yourself.

---

If you want a more Complex approach you can just simply use List but make the consumer of this list handle each kind of type. Which is basically the idea behind the DebuggerTypeProxy-Atrribute

So you can for example use some pattern like this:

foreach(var typeGroup in additionalInformation.GroupBy(item => item.GetType())
{
    ITypedLogHandler handler = GetHandlerFor(typeGroup.Key);
    handler.WriteLog(typeGroup);
}

In general the only reason I can think of this whole idea to beeing valid is some convenient debuggint/loggin approach. Anything else should really use strong typing.