Four Kinds of Optimisation (2023)
tratt.net
Four Kinds of Optimisation (2023)
1–10 of 16 posts
Re: Four Kinds of Optimisation (2023)
#2The first thing I thought when I saw your code was “what about optimizing for readability?”
Re: Four Kinds of Optimisation (2023)
#3Optimize for maintainable (readable) code with sane, understandable flows. then optimize for the user experience. Processors complete lifetimes when a human blinks. If you're doing /meaningful/ work with those cycles, that's fine. If it's bloat... trim bloat.
Re: Four Kinds of Optimisation (2023)
#4I've spent a lot of time jumping in to optimise horrendously complicated programs and data pipelines and things. The big wins are from understanding the domain and spotting all the inevitable misunderstandings and unnecessary steps that creep in when systems are so big they get split up and built/maintained by different people at different times.
Re: Four Kinds of Optimisation (2023)
#5The first thing I thought when I saw your code was “what about optimizing for readability?”
APL programmers would say it's already maximally optimized for readability (actually, it could be improved further with less and shorter keywords and stdlib function names).
That's not even a joke or dig at APL programmers, whether that code would be more or less readable with longer, more descriptive names is entirely a matter of perspective, preference, and context.
Re: Four Kinds of Optimisation (2023)
#6This is missing the 5th and most important optimization technique: don't pessimize the code in the first place.
The usual culprit is "premature modularization", where code that is used in one place and is never going to be extended is nonetheless full of indirections.
Re: Four Kinds of Optimisation (2023)
#75. Use a higher level system that can offer better optimizations.
This can include more advances VM or using other advanced problem oriented systems like databases or problem solvers.
Re: Four Kinds of Optimisation (2023)
#8This is missing the 5th and most important optimization technique: don't pessimize the code in the first place. The usual culprit is "premature modularization", where code that is used in one place and is never going to be extended is nonetheless full of indirections.
In principle it can in general fit the points 1-3 when you view less abstractions as lower level system and code as a data structure and algorithm, what can also include different levels of parallelism.
Re: Four Kinds of Optimisation (2023)
#9Previous discussion from 2023: https://news.ycombinator.com/item?id=38262251
Recent discussion on the follow-up, "The Fifth Kind of Optimisation": https://news.ycombinator.com/item?id=43555311
Re: Four Kinds of Optimisation (2023)
#10> it may well be fast enough, which is what really matters.
This deserves to be a headline in most optimisation discussions. Fast enough or small enough is often all that matters, start there.