To summarise the advice from today
Start with the simplest possible code.
Measure. Profile your code to identify the bottlenecks, don't guess.
If performance is good, stop. You don't need to optimise everything, only the hottest parts of your code.
For most applications where performance is a concern, the 80/20 rule applies. 80% of the time will be spent in 20% of the code--Knuth argues the number is closer to 3%.
As your application grows, or your traffic pattern evolves, these performance hot spots will change.
Don't leave complex code that is not performance critical, rewrite it with simpler operations if the bottleneck moves elsewhere.
Always write the simplest code you can, the compiler is optimised for normal code. I'm not going to say Idiomatic because I don't like how we use that word when discussing Go. So I'll just say simple, not clever, code.
Shorter code is faster code; Go is not C++, do not expect the compiler to unravel complicated abstractions.
Shorter code is smaller code; which is important for the CPU's cache.
If a program is too slow, it must have a loop -- Ken Thompson
Most programs perform well with small amounts of data. This is the essence behind Pike's 3rd rule.
However when the data set is large anything that touches the input set more than once, ie for every element in the set, test it against every other element in the set, has the potential to be a large performance headache.
Limit the communication and points of co-ordination between the parts of your program to ride Amdahl's law.
Network/disk io >> allocations >> function calls
If your program is dominated by network or disk access, don’t bother optimising allocations. Work on buffering and batching to reduce the amont of time spent waiting for io.
If your program is allocation bound, don’t bother optimising functions for inlining, loop unrolling, etc.
Pay very close attention to allocations, avoid unnecessary allocation where possible.
I can make things very fast if they don't have to be correct. -- Russ Cox
Finally, don't trade performance for reliability.
Readable means reliable -- Rob Pike
Performance and reliability are equally important. I see little value in making a very fast server that panics, deadlocks or OOMs on a regular basis.