none
Why is reflection so so so so slow? RRS feed

  • Question

  • So I wrote a generic routine that would take the results of a query (DataRow) and assign them to the appropriate object's properties (FieldNames and property names were the same).  I didn't want to have to code the individual assign for each and every field so I thought I'd use some System.Reflection since the object/class property names matched exactly the SQL query returned record field names.

    Oh what a BIG mistake that was ... I measured the performance with and without reflection.

    Without reflection < 1 sec

    With reflection > 22 sec

     The performance is so bad, I kinda almost wonder why it even exists?

    Rob

    Friday, September 28, 2012 9:16 PM

Answers

  • Reflection requires a lot of inspection at runtime, which causes a huge amount of overhead compared to normal method calls.  This, of course, is going to make it slower.

    It isn't really intended to be a replacement for general purpose development - it allows a lot of things to work that wouldn't otherwise be possible, though, as you can write code that doesn't know about the types involved and still is able to work with them.

    That being said, for something like this, there are typically ways to still use reflection but dramatically improve your speed.  For example, if you make a delegate for the set operations in each property, you can call the delegates instead of using reflection for each row, which would likely get your 22 seconds back down near 2 seconds (guessing, but that's about right if your original was <1 and the new is >22).   Delegate.CreateDelegate can build the delegate, then you're doing a normal delegate invocation instead of having to look up everything each time.  For details, see: http://stackoverflow.com/a/2824409/65358


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Friday, September 28, 2012 11:02 PM
    Moderator
  • Everything is slower than directly assigning values to the properties of a class. Reflection comes in handy whenever execution time is not a big issue, otherwise it could indeed become a bottleneck. If you can avoid Reflection, for example by using typed datasets, then do it. In some scenarios though, for example when you are dealing with small data, there is no real difference to the end user's experience. Reflection is slow. While caching does indeed save you some time the second time you use it (as you don't have to look up everything anew), you still have to pay a big price of using reflection the first time you use it. Loading metadata from an assembly into the memory at runtime is a costly thing to do. And you can't fully avoid it. If you cached everything nicely, as Reed Copsey suggested, you're almost done with reflection optimization. There are a few esoteric things you still could do (like pre-jitting methods etc.), but that will not make you happier. You'll have to decide between the coding convenience (also take into account code development/maintenance costs) and raw performance. If you opt in for the latter, you could also think about replacing the heavy DataRows/DataTables with DTOs filled from a DataReader.

    Marcel

    Saturday, September 29, 2012 10:59 AM

All replies

  • Reflection requires a lot of inspection at runtime, which causes a huge amount of overhead compared to normal method calls.  This, of course, is going to make it slower.

    It isn't really intended to be a replacement for general purpose development - it allows a lot of things to work that wouldn't otherwise be possible, though, as you can write code that doesn't know about the types involved and still is able to work with them.

    That being said, for something like this, there are typically ways to still use reflection but dramatically improve your speed.  For example, if you make a delegate for the set operations in each property, you can call the delegates instead of using reflection for each row, which would likely get your 22 seconds back down near 2 seconds (guessing, but that's about right if your original was <1 and the new is >22).   Delegate.CreateDelegate can build the delegate, then you're doing a normal delegate invocation instead of having to look up everything each time.  For details, see: http://stackoverflow.com/a/2824409/65358


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Friday, September 28, 2012 11:02 PM
    Moderator
  • Everything is slower than directly assigning values to the properties of a class. Reflection comes in handy whenever execution time is not a big issue, otherwise it could indeed become a bottleneck. If you can avoid Reflection, for example by using typed datasets, then do it. In some scenarios though, for example when you are dealing with small data, there is no real difference to the end user's experience. Reflection is slow. While caching does indeed save you some time the second time you use it (as you don't have to look up everything anew), you still have to pay a big price of using reflection the first time you use it. Loading metadata from an assembly into the memory at runtime is a costly thing to do. And you can't fully avoid it. If you cached everything nicely, as Reed Copsey suggested, you're almost done with reflection optimization. There are a few esoteric things you still could do (like pre-jitting methods etc.), but that will not make you happier. You'll have to decide between the coding convenience (also take into account code development/maintenance costs) and raw performance. If you opt in for the latter, you could also think about replacing the heavy DataRows/DataTables with DTOs filled from a DataReader.

    Marcel

    Saturday, September 29, 2012 10:59 AM