Ask HN: How can I learn about performance optimization?

For several years I have worked primarily with performance optimizations in the context of video games (and previously in the context of surgical simulation). This differs subtly from optimization in certain other areas, so I figured I'd add my own perspective to this already excellent comment section.

1. First and foremost: measure early, measure often. It's been said so often and it still needs repeating. In fact, the more you know about performance the easier it can be to fall into the trap of not measuring enough. Measuring will show exactly where you need to focus your efforts. It will also tell you without question whether your work has actually lead to an improvement, and to what degree.

2. The easiest way to make things go faster is to do less work. Use a more efficient algorithm, refactor code to eliminate unnecessary operations, move repeated work outside of loops. There are many flavours, but very often the biggest performance boosts are gained by simply solving the same problem through fewer instructions.

3. Understand the performance characteristics of your system. Is your application CPU bound, GPU compute bound, memory bound? If you don't know this you could make the code ten times as fast without gaining a single ms because the system is still stuck waiting for a memory transfer. On the flip side, if you know your system is busy waiting for memory, perhaps you can move computations to this spot to leverage this free work? This is particularly important in shader optimizations (latency hiding).

4. Solve a different problem! You can very often optimize your program by redefining your problem. Perhaps you are using the optimal algorithm for the problem as defined. But what does the end user really need? Often there are very similar but much easier problems which are equivalent for all practical purposes. Sometimes because the complexity lies in special cases which can be avoided or because there's a cheap approximation which gives sufficient accuracy. This happens especially often in graphics programming where the end goal is often to give an impression that you've calculated something.

I am so fascinated by how differently people interpreted this thread, really shows the diversity of computing and performance work. Here's a book about performance in the context of "enterprise and the cloud".

I've worked with performance optimizations for years, but never touched a network connection. Because for me it's all in the context of optimizing single player video games, which primarily leads to a focus on graphics programming and GPU performance.

Measure everything and be extremely critical. Be ready to challenge common and popular held assumptions.

Here is something I wrote about extreme performance in JavaScript that is discarded by most programmers because most people that program JavaScript professionally cannot really program.

https://github.com/prettydiff/wisdom/blob/master/performance...

Please do read a bit about history of TCP and how latency impacts the overall throughout. It's a classic thing and applies to any processing where you need results of some steps to proceed.

> Note "faster" is not the only thing to optimize for

That is very true! I simply think of it first because it is often the biggest problem at my work. One of the extreme exceptions was optimising Wavetale for the Nintendo Switch, where we had to decrease memory usage from over 20GiB to below 3GiB.

> is actually a bit unusual as it doesn't represent an exhaustible resource.

Not in the context of game development, however! There you typically don't care about wall time. Instead, you work towards a set frame rate meaning you have a set slice of time (usually 16.7 or 33.3 ms) to go through the entire game and render loop each time.