反射有多慢

In most cases: more than fast enough. For example, if you are using this to create a DAL wrapper object, the time taken to create the object via reflection will be minuscule compared to the time it needs to connect to a network. So optimising this would be a waste of time.

If you are using reflection in a tight loop, there are tricks to improve it:

• generics (using a wrapper where T : new() and MakeGenericType)
• Delegate.CreateDelegate (to a typed delegate; doesn't work for constructors)
• Reflection.Emit - hardcore
• Expression (like Delegate.CreateDelegate, but more flexible, and works for constructors)

But for your purposes, CreateInstance is perfectly fine. Stick with that, and keep things simple.

Edit: while the point about relative performance remains, and while the most important thing, "measure it", remains, I should clarify some of the above. Sometimes... it does matter. Measure first. However, if you find it is too slow, you might want to look at something like FastMember, which does all the Reflection.Emit code quietly in the background, to give you a nice easy API; for example:

var accessor = TypeAccessor.Create(type);
List<object> results = new List<object>();
foreach(var row in rows) {
object obj = accessor.CreateNew();
foreach(var col in cols) {
accessor[obj, col.Name] = col.Value;
}
results.Add(obj);
}

which is simple, but will be very fast. In the specific example I mention about a DAL wrapper—if you are doing this lots, consider something like dapper, which again does all the Reflection.Emit code in the background to give you the fastest possible but easy to use API:

int id = 12345;
var orders = connection.Query<Order>(
"select top 10 * from Orders where CustomerId = @id order by Id desc",
new { id }).ToList();

Here are some links that might help:

• This guy did some tests and provides a few metrics. This article is from 2006, so I made a Gist of the code to test Reflection Performance. The results are similar (although it's much faster now obviously).

   Constructor
  Time elapsed (ms): 15 which is 151588 ticks for 1000000 calls.
  
  
  Constructor using reflection
  Time elapsed (ms): 38 which is 381821 ticks for 1000000 calls.
  
  
  Method call
  Time elapsed (ms): 5 which is 57002 ticks for 1000000 calls.
  
  
  Method call using reflection
  Time elapsed (ms): 252 which is 2529507 ticks for 1000000 calls.
  
  
  Setting properties
  Time elapsed (ms): 294 which is 2949458 ticks for 1000000 calls.
  
  
  Setting properties using reflection
  Time elapsed (ms): 1490 which is 14908530 ticks for 1000000 calls.
  

• MSDN article "Dodge Common Performance Pitfalls to Craft Speedy Applications"

Other than following the links given in other answers and ensuring you're not writing "pathalogically bad" code then for me the best answer to this is to test it yourself.

Only you know where you bottle necks are, how many times your reflection code will be user, whether the reflection code will be in tight loops etc. You know your business case, how many users will access your site, what the perf requirements are.

However, given the snippet of code you've shown here then my guess would be that the overhead of reflection isn't going to be a massive problem.

VS.NET web testing and performance testing features should make measuring the performance of this code pretty simple.

If you don't use reflection, what will your code look like? What limitations will it have? It may be that you can't live with the limitations that you find yourself with if you remove the reflection code. It might be worth trying to design this code without the reflection to see if it's possible or it the alternative is desirable.

Reflection is not THAT slow. Invoking a method by reflection is about 3 times slower than the normal way. That is no problem if you do this just once or in non-critical situations. If you use it 10'000 times in a time-critical method, I would consider to change the implementation.

Its slower compared to non-reflective code. The important thing is not if its slow, but if its slow where it counts. For instance, if you instantiate objects using reflection in web environment where expected concurency can rise up to 10K, it will be slow.

Anyway, its good not to be concerned about performance in advance. If things turns out to be slow, you can always speed them up if you designed things correctly so that parts that you expected might be in need of optimisation in future are localised.

You can check this famous article if you need speed up:

Dynamic... But Fast: The Tale of Three Monkeys, A Wolf and the DynamicMethod and ILGenerator Classes

I was doing somethign similar until I started playing with IoC. I would use a Spring object definition to specify the data provider - SQL, XML, or Mocks!

I thought I'd do a quick test to demonstrate how slow reflection is compared to without.

With Reflection

• Instantiating 58 objects by iterating through each of their Attributes and matching

• Total Time: 52254 nanoseconds

  while (reader.Read()) {
  string[] columns = reader.CurrentRecord;
  CdsRawPayfileEntry toAdd = new CdsRawPayfileEntry();
  IEnumerable<PropertyInfo> rawPayFileAttributes = typeof(CdsRawPayfileEntry).GetProperties().Where(prop => Attribute.IsDefined(prop, typeof(CustomIndexAttribute)));
  foreach (var property in rawPayFileAttributes) {
  int propertyIndex = ((CustomIndexAttribute)property.GetCustomAttribute(typeof(CustomIndexAttribute))).Index;
  if (propertyIndex < columns.Length)
  property.SetValue(toReturn, columns[propertyIndex]);
  else
  break;
  }
  }
  

Without Reflection

• Instantiating 58 Objects by creating a new object

• Total Time: 868 nanoseconds

      while (reader2.Read()) {
  string[] columns = reader2.CurrentRecord;
  CdsRawPayfileEntry toAdd = new CdsRawPayfileEntry() {
  ColumnZero = columns[0],
  ColumnOne = columns[1],
  ColumnTwo = columns[2],
  ColumnThree = columns[3],
  ColumnFour = columns[4],
  ColumnFive = columns[5],
  ColumnSix = columns[6],
  ColumnSeven = columns[7],
  ColumnEight = columns[8],
  ColumnNine = columns[9],
  ColumnTen = columns[10],
  ColumnEleven = columns[11],
  ColumnTwelve = columns[12],
  ColumnThirteen = columns[13],
  ColumnFourteen = columns[14],
  ColumnFifteen = columns[15],
  ColumnSixteen = columns[16],
  ColumnSeventeen = columns[17]
  };
  }
  

Albeit, not completely fair since the reflection also has to retrieve a specific attribute of every property 58*18 times on top of creating a new object via reflection, but it at least provides some perspective.