Karl Seguin

Micro-optimization is a slippery slope, THAT's why it's so stupid to do: where will you draw the line? Perhaps writing EVERYTHING in hand-optimized assembler is faster! :) I think if you write everything not in a .net language but in hand-optimized x86 asm it might be faster, don't you think? ;)

Do you see the sillyness in this? What you should do is look for a better algorithm. That's what brings performance on the table. Optimizing searching a string is a good example. Say you start with the first character and so on... is that fast? No, there are faster algo's than that. However if you use the slow algo, optimize the crap out of your code, you still will be beaten by a slow implementation of a much faster algo.

Sure, the code you write shouldn't be unnecessarily slow, however the focus shouldn't be on that. So if you think you need MSIL statements... you really are on the wrong track.

Sure it's dangerous, but developers need to achieve a balance. If we always just listened to the man, no one would be using o/r mappers.

To me, this is (like most things) comes down to discipline. First you need to recognize that you even have the time to explore a [potentially useless] alternative. Next you need to be diligent about whether or not it should be implemented. Finally, you need to mentally catalog your findings for next time.

I don't plan on writing MSIL statements, but I do think understanding it could come in quite handy. This is along the same point as Spolsky saying developers ought to know C (which I fully agree with).

But i thought the cool kids were all "avoid premature optimization"....?

I would spend the time learning the JIT/CLR as opposed to IL if you want to learn about micro-optimizations, the JIT optimizes away alot of stuff that you may think as bad looking at IL...

That and a spend time with reflector looking at the framework classes. A perfect example of a the benefit herewould be to prefer a LinkedList<T> over a List<T> when you are adding and removing alot of nodes in a large list.

To be honest I find that micro-optimizations should only be applied to about 10% of code.

Why should you optimize before you know that your code is slow?

If your code is designet well and you have test for everything, you can optimize things after you have run your load tests.

The need for optimizing is maybe not there even if your think so, maybe you should approach the problem from a different angel. Is there some way that you can make a user become happy with your slow code?

The need for optimizing should be driven by your application type. A game that needs fps needs optimizing, no doubt about that. A forms or web application seems not to be the biggest candidates for optimization.

Why waste time on optimization when you can give your customers hard needed functionality

Benny:

You should optimize, not for the sake of optimizing, but for the sake of learning. As the years roll on and managed languages assert themselves almost fully, important knowledge is being lost.

I don't think people should use foreach loops instead of for loops, but I DO think they should understand the difference. Maybe not down to the IL, but at least enough to establish a foundation.

>>"Why waste time on optimization when you can give your customers hard needed functionality"

I think that sums up our difference in opinion. Your right if you just seem optimization as a means to improve performance and it isn't at all necessary. However, I honestly believe optimizations, whether they are necessary or not, are one of the few opportunities in the managed world to get somewhat close to the machine. Languages are very far away from making that a waste of time.

Your last point is really where you and I don't see ei

One of my gripes is the misquoting of Hoare being used as an excuse to write slow code.   The entire quote is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.".  This means you still have to check to see if optimization is needed to ensure the code isn't in that magic 3% that does need optimization.

My gripe  is that you should choose the most efficient algorithm for the task at hand, and that's not a premature optimization--despite that many people would claim it's a premature optimization.  The time it takes to write code that concatenates strings with the + operator and the time it takes to write code that uses StringBuilder is the same.  When you choose StringBuilder over operator+ you're not prematurely optimizing.  Changing operator+ to use StringBuilder would be considered premature optimization.

But yes, you have to run performance tests from time to time when performance is at issue; which means you have to micro optimize from time to time.

At first, I started to have a gut reaction against what you were saying.  Usually this is because those micro-optimizations come in the form of brittle, procedural code.  Later in your post, you jumped into unit testing and TDD.

Generally speaking, if you can do microoptimizations in a test-driven fashion, I'm quite ok with them.  The fact that they are test driven with OOP principles in mind should ensure their maintainability (assuming that's done well).

The knee-jerk reaction a lot of us have is from seeing the "optimized" procedural code we've seen in the past, where you end up having to rewrite it all when you change it (and the optimization was never really needed in the first place).

My preferred method of working, however, is different.  I'd rather write the simplest thing that works for now (passes my user story and makes my tests green) and then watch the unit test execution time and integration tests to determine what actually needs deeper attention.

Evan,

Thanks for keeping an open mind and reading it all the way through :)

We're actually going through a round of performance testing and optimizing, and the unit tests are providing the team with an unbelievable amount of confidence that changes made won't break any business rules.