[falcolas]

This is fairly specific optimization advice which applies to only a subset of people's code, but: Write your own SQL queries.

ORMs are notorious for writing inefficient queries once you get more complicated than selecting a single row from a simple table, and trying to optimize them without writing a SQL query will make your code all but unreadable. This isn't to say don't use an ORM, but if you need to optimize, your code speed and code clarity will be better off with raw SQL.

More generalized performance advice: Keep heap memory allocations to an absolute minimum. Heap access is more likely to result in cache misses, and the bookkeeping related to allocating and freeing memory can quickly add up (even if you're not doing it explicitly).

Globals and stack allocations are almost universally faster.

A resource which popped up on HN yesterday might offer a bit more insight on how to design for optimal performance: https://news.ycombinator.com/item?id=8978081

[mgkimsal]

Log and time your SQL queries, don't assume they'll always be worse. Sometimes you get bad SQL generated because ... the tables/objects were not set up properly in the first place.

I'm an ORM-first person, and look for slow queries at certain points in development. Usually about 90+% of the queries from the ORM layer are fine and 10% need to be rerolled by hand for better performance.

The other thing about ORMs I've learned in the last few years is that often you're not really needing an object back in the first place, if you're just reading the results vs modifying/saving. Hibernate projections (IIRC) just give you back a map, and save the overhead of trying to create an object (or object graph) to hand back.