Live data from Hacker News

Ask HN: How can I learn about performance optimization?

news.ycombinator.com

101–110 of 153 posts

Re: Ask HN: How can I learn about performance optimization?

#102
post #77
post #76

Former HFT dev here. Know fundamentals: sources of performance issues = things that eat/waste CPU cycles, things that reach too far down the memory hierarchy. Usually the latter. E.g. L2 cache to RAM - order of magnitude slower; RAM to disk: 4+ orders of magnitude slower. Things that eat CPU: iterations, string operations. Things that waste CPU: lock contentions in multi-threaded environments, wait states. You can us…

Addendum: never forget Amdahl's Law. And never forget Knuth's full quote: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is th…

This ideology is exactly why we have bloated abominations like Slack electron apps.

Re: Ask HN: How can I learn about performance optimization?

#104

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 easiest way to make things go faster is to do less work

This is a great rule of thumb. I've seen junior engineers (and even senior in some cases) try to parallelize existing solutions before first optimizing the single threaded case.

Re: Ask HN: How can I learn about performance optimization?

#105
post #76

Former HFT dev here. Know fundamentals: sources of performance issues = things that eat/waste CPU cycles, things that reach too far down the memory hierarchy. Usually the latter. E.g. L2 cache to RAM - order of magnitude slower; RAM to disk: 4+ orders of magnitude slower. Things that eat CPU: iterations, string operations. Things that waste CPU: lock contentions in multi-threaded environments, wait states. You can us…

> Until very recently, re-rendering with virtual DOM diffing was considered more performant than direct, incremental DOM manipulation. This too, may no longer be true.

Actually wasn't strictly true even when React came out, but it was true enough with the code that most JS developers actually wrote to lead to a change in dominant JS framework.

DOM manipulation even in 2013 used a dirty-bit system. Calling element.appendChild would be a few pointer swaps and take a couple ns. However, if you then called any of a number of methods that forced a layout, it would re-render the whole page at a cost of ~20ms on mobile devices of the day. These included such common methods as getComputedStyle(), .offsetWidth, .offsetHeight, and many others - there was a list of about 2 dozen. Most JS apps of the day might have dozens to hundreds of these re-layouts triggered per frame, but the frame budget is only 16.667ms, so that's why you had slow animations & responsiveness for mobile web apps of 2013.

React didn't need a full virtual DOM layer. It just needed to ensure that all modifications to the DOM happened at once, and no user code ran in-between DOM manipulations within a certain frame. And sure enough, there are frameworks that actually do this with a much lighter virtual DOM abstraction (see: Preact) and get equal or better performance than React.

The lesson for performance tuning is to understand what's going on, don't just take benchmarks at face value. If a call is expensive, sometimes it's conditionally expensive based on other stuff you're doing, and there's a happy path that's much faster. Learn to leverage the happy paths and minimize the need to do expensive work over and over again, even if the expensive work happens in a layer you don't have access to.

Re: Ask HN: How can I learn about performance optimization?

#107
post #77
post #76

Former HFT dev here. Know fundamentals: sources of performance issues = things that eat/waste CPU cycles, things that reach too far down the memory hierarchy. Usually the latter. E.g. L2 cache to RAM - order of magnitude slower; RAM to disk: 4+ orders of magnitude slower. Things that eat CPU: iterations, string operations. Things that waste CPU: lock contentions in multi-threaded environments, wait states. You can us…

Addendum: never forget Amdahl's Law. And never forget Knuth's full quote: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is th…

The problem is, instead of internalizing the whole quote, which is valid in my opinion, many have only internalized the "root of all evil" part. This roughly translates to "my feature is done - performance is someone else's problem".

Re: Ask HN: How can I learn about performance optimization?

#108

You’re unlikely to find a good answer because it’s a very specialized skill that is mostly from experience doing it, and HN tends to self select out of that pursuit.

Noticed a few experts were mentioned but their advice was already dismissed.

Re: Ask HN: How can I learn about performance optimization?

#109
Plugging the book that I just published: https://a.co/d/iTjaQzP

It's a beginner-friendly introduction to Low Latency Programming, which involves a lot of performance optimization. Could be a good way to start your learning on the subject.

You can read one of the chapters on my blog: https://tech.davidgorski.ca/introduction-to-low-latency-prog...

Re: Ask HN: How can I learn about performance optimization?

#110
Suggestion: Program some (slow) microcontrollers as a hobby.

Go multi-core because async is an important optimization skillset, but other than that just build some things.

I live and breathe optimizations (it feels almost as satisfying to me as driving fast) and as an example recently I created an 11-board (one for each channel) wifi-presence-detection system in a busy wifi area and there was literally no way it was going to work without optimization. From communication protocol to having to be strict about every byte of memory, it’s working with the first principles that built the entire industry.

Post reply on HN