This is so important:

  Do not even try to write what you think is effective code before 
  benchmarking. The VM has many clever optimizations. And even if 
  you will somehow learn of all of them, in the next release they 
  still can be changed. Instead, write a simple and clean piece of 
  code, make a benchmark, find the real bottleneck and rewrite code 
  in small parts.

Every now and then I see some strange code at a client I work with, and the justification is "Performance". Because somebody thought it might be faster - But they didn't check it back then. And they don't have an automated performance test that continuosly validates if their "dirty but fast" code is still faster than the clean version...

Don't even ask how many hours of developer time I saw wasted because of "dirty but fast" code. Where the code often was not much faster then the clean version. Or it was faster, but speed was not crucial in the area where the code operated.

Also, I guess a lot of the optimizations from old blog posts or the first "Effective Java" will not yield amazing results anymore, as compilers and runtimes are getting better.

I also like this one:

  Do not think that programming in C++ or any other lower-level language
  is a must for having good performance. Good architecture, benchmarking 
  and profiling are far more important.

But I don't think it is as clear-cut as the author writes it. For some problems, having total control over your memory layout and what gets exectued when (i.e. C or C++ or ...) can lead to huge benefits. And sometimes, the runtime is just more clever optimizing the code than you are.