Ask HN: How can I learn about performance optimization?
101–110 of 153 posts
Re: Ask HN: How can I learn about performance optimization?
#102Former 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…
Re: Ask HN: How can I learn about performance optimization?
#103Re: Ask HN: How can I learn about performance optimization?
#104For 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,…
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?
#105Former 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…
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?
#106Re: Ask HN: How can I learn about performance optimization?
#107Former 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…
Re: Ask HN: How can I learn about performance optimization?
#108You’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.
Re: Ask HN: How can I learn about performance optimization?
#109It'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?
#110Go 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.