This post originated from an RSS feed registered with .NET Buzz by Udi Dahan. Original Post: This "performs" better than that - who cares ? Feed Title: Udi Dahan - The Software Simplist Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple. This blog is about how I do it. Latest .NET Buzz Posts Latest .NET Buzz Posts by Udi Dahan Latest Posts From Udi Dahan - The Software Simplist

Once again, I've gotten all riled up - and after 1:00am. But I can't hold myself back. I just ran into another post about which string concatentation mechanism is more performant. Now, performance is something not to be taken lightly, and the "who cares" in the title may lead some people to believe that I don't care about performance, but let me just quote myself from some thoughts about the performance of Shadowfax from last week's question of the week:

"The main thing that I need in the performance area is this:

I want to know, at any given moment, what the current bottleneck/constraint is, where it is, and at different resolutions.

If average system throughput is 100 tps, I want to know why. I want analysis capabilities. I want monitoring. I want to know if I need to add hardware, and where.

I couldn't care less about 50% overhead if I could get all the things I mentioned above. "

This is what system performance is about. Once I have this ( and I think that it'll take a while before I get it ), I can easily zoom in on a bottleneck, find out which code is problematic, and why.

After all this, I may find that string concatenation is the problem, and then I'll go and solve it.

My point is this: from the number of posts and articles online and offline about string concatenation, you'd think that it's the root of all performance problems !

People, wake up ! You want performance ? Architect for it ! Design for it ! I'm not talking about "writing performant code" or some other tidbit of advice. I'm talking about:

1. How do I know there's a problem

2. If I know there's a problem, how do I find the problem

3. How do I know what kind of problem it is - memory, cpu, network, or maybe I just need to start scaling out, or up.

Once you have this, everything else becomes trivial. So, for all the performance wizards out there, lets start focusing on the real problems, not just the problems that have straight-forward solutions.