How slow is Reflection
Solution 1
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()
andMakeGenericType
) -
Delegate.CreateDelegate
(to a typed delegate; doesn't work for constructors) -
Reflection.Emit
- hardcore -
Expression
(likeDelegate.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();
Solution 2
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
Solution 3
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"
Solution 4
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.
Solution 5
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.
Related videos on Youtube
user29964
Updated on July 05, 2022Comments
-
user29964 almost 2 years
I recently created an interface layer to distinguish the DataAccessProvider from our Business logic layer. With this approach we can change our choice of DataAccessProvider whenever we want by changing the values in the Web/App.Config. (more details can be given if needed).
Anyway, to do this we use reflection to accomplish our DataProvider class on which we can work.
/// <summary> /// The constructor will create a new provider with the use of reflection. /// If the assembly could not be loaded an AssemblyNotFoundException will be thrown. /// </summary> public DataAccessProviderFactory() { string providerName = ConfigurationManager.AppSettings["DataProvider"]; string providerFactoryName = ConfigurationManager.AppSettings["DataProviderFactory"]; try { activeProvider = Assembly.Load(providerName); activeDataProviderFactory = (IDataProviderFactory)activeProvider.CreateInstance(providerFactoryName); } catch { throw new AssemblyNotFoundException(); } }
But now I'm wondering how slow reflection is?
-
marijne about 15 yearsSurely it would be trivial to create a test harness to benchmark this?
-
nawfal almost 11 years
-
-
user6170001 about 15 yearsDon't be shocked. The longest time measured was 22 seconds for a million iterations. 22 microseconds per call for the worst case. Unless you're creating a huge number of these objects, it's really not a big deal. Of course, if you are creating a huge number of these objects, then it might be a big deal, but as Marc notes it's still going to be swamped by the database connection and query times. Don't be freaked out by "x times as slow" articles unless you know it's performance-critical.
-
Ruben Steins about 15 yearsI agree, even though it is slower, for most applications, the performance penalty will not outweigh the benefits of using Reflection.
-
Jacob almost 15 yearsSpring.net is quite capable of updating dependencies at runtime. If you update the config file and reload an instance from the factory, you'll get a reference to the updated instance. (Note that this does not work if you load the config from app.config, only if you use a separate spring XML file.
-
Seng Cheong about 12 yearsIf this is true, I really like this statement. "Invoking a method by reflection is about 3 times slower than the normal way." Do you have any references?
-
Enyra about 12 yearsUf my post is about 3 years old, I cant remeber from where I got this information.
-
Daniel Bişar over 11 yearsIf someone wants to see how the reflection emit works for accessing fields (it's not too complicated) See: sharpanalytics.blogspot.de/2012/08/…
-
Loathing almost 10 yearsI converted a data access layer from the FieldInfo and PropertyInfo GetValue SetValue to the compiled expression. The time it took to read 30,000 rows with 40 columns went from 4 seconds down to 1 second. However, in a side-by-side comparison, reflection is between 200 and 250 times slower than a compiled expression when setting and getting values.
-
Sangram Nandkhile over 8 years@Marc: I've been using reflection to get method, class name of current method to log the error in try-catch. basically to avoid hardcoding the function name while logging error. Do i need to worry?
-
Marc Gravell over 8 years@Sangram probably not, no