Trust performance advice... but verify.

Or how to listen to your compiler.

Just like most things, performance advice also has an expiration date and it's important to keep this in mind when applying suggestions from blog posts or StackOverflow. That's why my favorite command line flag when building Go apps is --gcflags="-m=2". It enables printing optimizer decisions, making it possible to answer numerous interesting questions affecting performance, including whether function is inlined:

or whether variable escapes to heap:

Bonus: do you think l will escape to heap in the following code?

If you guessed yes, you are right :)

Why it matters? Even if the additional memory indirection is not a problem, heap allocations result in extra work for garbage collector and dreaded stop-the-world pauses.

Moral of the story? Know your tools and use them to verify all performance assumptions.