How do programming/design decisions affect performance under the hood?

Question

Hi,

In the current project I am working on I have come across a piece of code which seems to be overblown. I considered rewriting it to avoid more objects in memory than need be, and had trouble making a decision about whether the performance benefits from refactoring would be worth the time, and whether the current design will impact performance at any stage through out the application lifetime and therefore need to be changed.

I realised I did not have the knowledge to answer these questions. What knowledge do I need to make accurate assessments of the performance of a code design? Does anyone know any good resources on C#/Java internal workings that would help my understanding?

Answer 1

There is a huge amount of information out there, particularly by researching on MSDN - but...

The only way you'll really know whether you need to take the time to refactor is to profile this code. If it's bloated in terms of memory or run times, you may want to take the time to refactor it. If it runs quickly, and doesn't actually take as much memory as you expect, the gains may not be worth the effort.

Code design alone is never enough - most of the time, if you're projecting a performance pattern based off a design, your projection will be wrong. Yes, there are cases where code is obviously horribly designed, but most of the time, the (small) part that will be the actual problem is not the part where you expect the problem to exist - it's often some other small piece of code somewhere you never expect...

Answer 2

Only rewrite it if you have trouble understanding it and maintaining it will be a nightmare. If you are rewriting solely for performance reasons, do not unless you know for sure it is causing a performance problem.

Answer 3

"...I have come across a piece of code which seems to be overblown..."

My advice would be to talk to the developer who originally wrote the code or someone else on the team who might know it well. I don't know what "overblown" means without seeing what you're seeing.

It might mean that refactoring is an order. If that's the case, one thing you can do to learn more about the code and prepare for refactoring is to start writing unit tests for it. Become familiar with what the class does, where its input comes from, the range of input, how it behaves, what exceptions it throws, who it collaborates with, etc. You'll learn a lot about that class/package and when you're done you'll have a nice safety net of unit tests to prove that changes you make don't break it. Even if you never actually refactor the class the effort will be helpful.

But be careful. Object creation isn't terribly expensive anymore for Java; I'll bet that C# does at least as well. If there's no data to support a memory or performance issue, don't assume that you can spot such a thing with your gut or experience.

Answer 4

I agree with Reed and DanDan, and this is somewhat of a tangent, but one thing I like doing is setting up stress tests for important or heavily used parts of our system using our existing (N)unit testing framework. That way you can define minimum acceptable performance levels and then see if the code is up to the task, if it's not, then look at refactoring.

Typically we have Assembly.Tests.dll along with Assembly.Stress.Tests.dll, and the stress tests normally have a small, medium, large and huge sample range of data, each with its own maximum time limit. This approach is mainly geared towards performance rather than memory usage.

Assuming you keep a log of your tests e.g. via a continuous integration server, you will get a long-term performance profile. Also, we don't run the stress tests for our CI builds, just the nightly builds.

Answer 5

Great question! Vance Morrison, CLR Perf architect wrote a 2 MSDN article to exactly address this question Check them out

http://msdn.microsoft.com/en-us/magazine/cc500596.aspx http://msdn.microsoft.com/en-us/magazine/cc507639.aspx

Hope this help Thanks

Answer 6

It's not a matter of having the right knowledge.

Anybody who says they just "know" what's costing time in that specific code, unless they've proven it by profiling or sampling, is really just guessing.

• Never guess when it comes to performance questions.

Everybody knows that, but they do it anyway.