XYZ Is Bad For Performance

After learning about the performance characteristics of .NET Reflection, you might be tempted to say that “Reflection is bad for performance”.  Roughly the same argument applies to string concatenation, out-of-process communication, context switching, virtual function calls…

If you follow this path blindly, you will end up saying that programming is bad for performance.

And as we all know, it is, but that doesn’t really lead us anywhere.  What I’m saying is that common sense needs be applied, as always, even to statements like “XYZ is bad for performance”.  Examples, good and bad:

A: We’re using .NET Remoting in our application to send the hourly report (consisting of over 100KB of data!) to a centralized server.

B: The performance cost of .NET Remoting is too high – there is serialization, data transfer and deserialization involved.  You need to roll out a custom solution over TCP to transfer the data every hour, and preferably compress it.

Nonsense, of course (and there’s also a severe cost-effectiveness problem lurking in that statement, even if it were somewhat true).  Awesome.  This one was easy.  Now, what about this one:

A: All the methods of my Vector and Matrix classes are virtual to maximize testability.  Even the properties are virtual so that I can mock them away.

B: Virtual methods and properties that are potentially called in tight loops are hazardous – especially if they are very short and could be inlined otherwise.  Make the critical operations non-virtual.

Hmm.  This could be right, it mainly depends on the scenario.  If I were writing a Vector class of my own, then I would probably expect it to be called in tight loops – that’s what these vectors are for, after all…  So in this context, virtual methods might be bad for performance.  All righty then, next:

A: I’m using Reflection to implement custom logging between the UI and BL layers of my application.  Whenever a user initiates an action in the UI, my generic code inspects the MethodBase.GetCurrentMethod() return value and prints out the name of the method called to a log file.

B: Reflection is very bad for your health!  The cost of retrieving the current method is overwhelming, and whenever you say Reflection you must forget about performance.

I call the B and S words on this one.  That’s what you’re worried about?  Reflection?  You have a custom logging framework writing data to a file, and Reflection is your concern?  And hey, how many times is the user going to click a button?!  Reflection for an operation that happens maybe once a second is perfectly reasonable.

I would be the last person to advocate against designing an application for performance and testing the results afterwards.  I’m just saying that if all you’ve got is the blind “this is bad for performance” hammer, then every programming problem becomes a nail.  And that’s hardly a way to design or implement anything.

 

References

Reference: 

“XYZ Is Bad For Performance”