Although I am a little curious about some of the less-mainstream theories: "Other hypotheses were untestable at best, such as claims that the bees were being abducted by aliens." With our pride, we always _assumed_ the aliens would _naturally_ want to abduct us!

"Don't abuse the text field in the submission form to add commentary to links. The text field is for starting discussions. If you're submitting a link, put it in the url field. If you want to add initial commentary on the link, write a blog post about it and submit that instead."

http://ycombinator.com/newsguidelines.html

1. Do we have to optimize this? Time is never free, and opportunity cost in terms of engineering effort is usually very significant.

2. Can we do less work? (this article)

3. What's the bottleneck? CPU, FP, memory bandwidth, lock contention?

4. How do we squeeze out better performance? Assembly, loop unrolling, etc.

I usually cringe when I hear about people talking about #4, as very few of them have asked #1, #2, or #3 yet.

And usually, you just hear people talking about doing what the compiler's already doing (writing it in assembly? /The compiler already does that/), usually doing a pretty reasonable job at high optimization levels. They just exchange maintainability for the warm fuzzy feeling that they've been as macho as needed.

Use the 80-20 rule. 80% of your code's time is spent in 20% of the code.

Optimizing without good profiling is like painting a portrait blindfolded.

Pre-optimizing by coding your system to be "fast" before you get to profile it is like starting to paint a portrait before your model is even sitting.

When Kent Beck came in to optimize the Chrysler C3 payroll system, he discovered that one of the biggest time-sinks in the system was string concatenation!

It's also useless to optimize before you have a system that runs correctly. Kent also asked how he could validate the C3 system so he could optimize it. He was told it wasn't even producing correct results yet. He replied: "In that case I can make it run really fast!"

Modern CPUs do not "execute a fixed number of instructions per second"; even leaving aside the fact that certain instructions are faster than others, factors such as the order in which you access memory locations and the predictability of branches can easily result in a tenfold difference in performance.

In many cases, code can be made faster by executing more instructions; I recently dealt with some code where changing a (theoretically) O(N) algorithm to an O(N log N) algorithm and increasing the number of operations by a factor of 10 nevertheless resulted in the code running twice as fast. Now, this was an extreme case -- the code went from accessing completely random memory locations to accessing completely sequential memory locations -- but it demonstrates the importance of memory access patterns.

Anyway, just give the man some respect, he is somewhat an extremist, but if it weren't for this guy you wouldn't be starting all these startups on shoestring budgets and I know that everyone in their heart of hearts knows that the world is a better place because of RMS.

If another seed firm did set its decision date a few days or weeks after, would you then give teams more time to decide?

That would be incredibly gracious of YC -- indeed beyond what I would expect of the category leader. But that seems to be the implication of your parenthetical.

And Python and Ruby both have excellent C bindings, you can rewrite CPU-intensive portions of your application pretty much anytime you need to.

If you're using Python or Ruby for CPU-intensive applications, you probably don't have a performance checklist.

I don't think there would need to be a common application, but there may have to be a common deadline.

This is worth taking note of. Particularly if your users aren't very web-savvy.