.NET Performance Tip #1
Posted by Terrance A. Snyder on July 12th, 2008I’ve seen some dramatic failures because people have waited till the end. Only until after they were ‘done coding’ did they get the shock that it takes 30 seconds for their application to return “Hello World” and that Hello World call took 99% of cpu utilization and 600MB of ram.
If there was any tip/trick to writing high performance applications it would be that performance goals should constantly be mentioned, examined, and logged from day one. I don’t know how many times I have seen teams crumble as deadlines approached to see their applications fail any reasonable performance metric.
The problem for them? THEY NEVER MEASURED IT IN THE FIRST PLACE.
If you reach the end, and you find yourself in this situation. Just stop what you are doing and examine your choices:
A.) Start throwing spaghetti at a wall and see what sticks. Hope above all else you’ll find some glaringly obvious design flaw that caused your performance problems, because there isn’t a chance in hell you’re going to be able to correct a performance problem because of architecture or worse, small little choices sprinkled in a huge code-base which may or may not have inverse relationships to each other.
B.) Re-write your application. Start with the smallest unit of code and start porting over the “bad” code as you go along. Continuously Integrating and evaluating your performance along the way keep a watchful eye on that performance #.
It’s sad really…. No I really mean it… It’s very sad…..
I’ve seen so many projects also go with choice A. Thinking (read: more like hoping) that somehow, someway, you could make a code base which was never monitored for performance, a codebase of say 30,000+ lines of code, meet performance expectations.
Out of those projects I’ve seen go with choice A, I’ve never seen one come up with a good solution. I’ve seen workarounds (see IT dictionary), and I’ve seen things crash and burn, but I’ve never seen a project that went with choice A succeed. It just will never happen… there is just too many variables unaccounted for.
So if your on a team with a poorly performing application scheduled to go into production….
Realize you have already missed the boat, accept it, and move on. Just don’t make your customers pay the price.

Recent Comments