I come from a DBA world and performance has always been an obsession. I am turning to development and I always think about performance, constantly, all the time.
Reading
Citing Knuth's 'premature optimization .. evil' is a poor argument for writing sloppy and slow code (correct or otherwise).
If you're writing a simple form to update some details, it's probably not worth optimizing.
If you're writing a google search engine replacement, and you expect to have a lot of traffic, then you figure out a way to make that search as fast as possible.
You only ever need to optimize code that counts, and there's a lot of code in a program for doing one-off things, or events that happen rarely.
Given that we satisfy 1, 2 and 3 above:
There's little point waiting until the app is 90% complete before doing any performance testing and optimization. Performance is often an unwritten non-functional requirement. You need to identify and write down what some of these unwritten requirements are and commit to them.
It's also probably too late by 90% complete if you need to make an architectural or other major changes. The more code that has been written, the harder it gets to change things, if only for the fact that there's more code to think about. You need to continually make sure that your app will perform when and where it needs to.
Then again, if you have well written unit tests you should be able to have performance tests as a part of those tests.
My 2 shillings at least.