Okey, so I’ve been asked to please keep posting workout pictures so I’ll throw in a couple a week and I’ll see how the response is (I really appreciate the emails, I haven’t had time to answer – but I will, to every single one 🙂 – I just don’t want to do it when I am in a hurry as I want to give proper replies). The pictures are from a run earlier today, in the pouring rain. Did a 50 min run, and then we did some outdoor strength training.
Now! A very important question, How does reflection affect performance, and should I avoid using it? I got so many great comments on my what is reflection post that I’ve decided to make this one a separate question and post the comments here.
The answer is , as I’ve understood it, that reflection does slightly affect performance – but VERY little. If performance isn’t a big issue and using reflection will allow you to write prettier code that is esier to read and maintain – then go for it.
Though reflection is slower than non-reflection, we are only talking about times in the nanosecond range. For example it calling a method normally takes 1 ns, with reflection it might take 3-5 ns. As always with performance: profile and find your bottleneck before optimizing. Keep the code clean and it will be easy to optimize later where it matters.
Reflection is good for handling situations which would otherwise be impossible to implement, or would require lots of boilerplate code. There are ways to do things faster than reflection (for example code generation at runtime or compile time), but those are much harder to use than reflection. (Based on my recent experiences, using bytecode manipulation or source code generation requires in the order of 10 times more work than using reflection.)
Some years ago I was practicing reflection (and TDD) by writing an application which can take as input a string “foo abc 123″ and then using reflection does the method call
foo("abc", 123) on an object. In nearly every project I’ve had some use for reflection, so it’s good to keep at hand in your toolbox.
July 23, 2012 at 5:26 pm (Edit)
Here is a good use of reflection along with some performance numbers.
James Curran says:
July 24, 2012 at 7:43 am
I’ve long felt the Reflection get a bad name due to it’s frequent misuse. There’s is nothing inherently slow about reflection; the problem is that it is often used for things that could be done much faster using inheritance/polymorphism or method overloading.
Daniel COHEN-ZARDI says: July 24, 2012 at 2:51 pm
Though powerful when used properly, reflection is often over-used.
The main issue is not performance, it is the fact that using a “dynamic” approach might make your software more robust and harder to maintain.
Once you get an error in production, it is much more complex to support and debug than a static approach.
In my view, to some extent, it is a little bit like using languages that have no types (or interpreted languages versus compiled languages). It is very powerful and flexible but has drawbacks when overly used.
SondreB says: July 27, 2012 at 12:57 am
As others have mentioned, reflection does not come with a very hard performance penalty, at least not these days. It depends on what you are doing.
The question is the trade off you need to do: Should you use reflection to save time, write less code and have less bugs – or write more code, possibly more bugs?