Over a million developers have joined DZone.

XYZ Is Bad For Performance

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

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.


Learn tips and best practices for optimizing your capacity management strategy with the Market Guide for Capacity Management, brought to you in partnership with BMC.


Published at DZone with permission of Sasha Goldshtein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}