Developers tends to be micro optimizers by default, in most cases. In general it is accepted that this is a Bad Thing. This is a very common quote:
In my last project, I wasn't willing to allow discussion on the performance of the application until we got to final QA stages. (We found exactly two bottle necks in the application, by the way, and it cost us 1 hour and 1 day to fix them). You could say that I really believe that premature optimization is a problem.
However, the one thing that I will think of in advance (hopefully far in advance), is reducing the amount of remote calls.
This is something that you should think of in advance, because a remote call is several orders of magnitudes than just about anything else that you can do in your application except maybe huge prime generation.
In general, you need to think about two things:
- How can we reduce remote calls?
- How can we fail (in development) for exceeding some amount of remote calls per a unit of work?
What I have found is that batching makes for a really nice model for reducing remote calls, and ensuring failure on high number of remote calls to be the most effective way to reduce their number.
This is generally not something that you can retrofit into the system, the model of work is completely different. You can try, but you end up with a Frankenstein that is going to be slow and hard to work with.
So, at any rate, this is what I wanted to say. Ignore performance until very late in the game, but do think about remote calls and the distribution of the application components as early as possible.
No, this is not BDUF, it is setting the architecture for the application, and having the right fundamental approach as early as possible.