You might want to consider the Rules Of Optimization Club. They've been written for Perl in mind, but I'm sure they apply in most cases. Repeated / amended below:
- Don't optimize.
- Don't optimize without measuring.
- If your app is running faster than the underlying transport protocol, the optimization is over.
- One factor at a time.
Or, in other words, "make it work, make it correct, and only then make it fast". I much rather have slow code which is correct, than very fast code which gives the wrong answer, performs the wrong calculation, or wreaks havoc.
As to the language of choice, I'm biased as this site's mainly Perl-based… but one surely has to consider the speed and ease at which things can be developed, and not only whether a few milliseconds can be shaved here and there. If gaining speed means having harder to read code, it might not be the best trade-off. It's not always best to optimize for development, rather than for runtime – but it can often be.
Just my 2c.