5 ms·

Balancing Optimization While Coding

42 points by breadchris 3y ago

sanitycheck 3y ago
> "As creators of software and websites, we often get caught up in the never-ending pursuit of optimization. We constantly strive to make our code more efficient, our algorithms faster, and our page load times shorter." I really wish this "problem" was more common!
- godelski 3y ago
  There's two types of devs. Those who are constantly tripping over rabbit holes while pondering what lies inside and those who ask what a rabbit is.
  - kalyantm 3y ago
    I'm completely agree with this. The people who like to dig deeper usually find structural issues that help you organise your tech debt and keep it maintainable. The other ones usually keep the ship moving forward and the product team happy, applying band-aid fixes where necessary. The key is to ensure that they are talking to each other!
    - godelski 3y ago
      > The key is to ensure that they are talking to each other! Yeah this is exactly how I see it too. You need both of these people. Even being a rabbit hole person myself, I know it is easy for us to get lost. But I think the issue is we are fewer in number and what we see isn't visible to others. But there is a deep synergy between our groups that we must balance.
  - fmbb 3y ago
    And deep down at the bottom of every rabbit hole lies a Yak waiting for a barber.
  - richrichie 3y ago
    Classic MBA vs PhD problem? In some domains people refuse to hire PhDs because of analysis-paralysis; they prefer the stupid MBAs who will take risks that PhDs will never take. In other, they avoid MBAs like plague because they are shallow know nothing organisms that leach on revenues.
    - I_ 3y ago
      Maybe the ultimate engineer would have an MBA and a PhD...
    - godelski 3y ago
      Both are naive. You need a balance.
    - AstralStorm 3y ago
      Thus you should hire proper BScs :)
- Tabular-Iceberg 3y ago
  Indeed. The only optimization I see in this industry is optimization for billable hours.
  - trey-jones 3y ago
    I'm just here to provide moral support for fellow cynics. Hang in there buddy, it will all be over soon. If we're lucky.
pasc1878 3y ago
And another person finds premature Optimisation. From https://wiki.c2.com/?PrematureOptimization https://wiki.c2.com/?PrematureOptimization Premature optimization is the root of all evil -- DonaldKnuth In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "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 the root of all evil. Yet we should not pass up our opportunities in that critical 3%." Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal.
- iamflimflam1 3y ago
  The key part that seems to be ignored by everyone who quotes Knuth is: "Yet we should not pass up our opportunities in that critical 3%"
  - n4r9 3y ago
    Exactly. He's not saying "don't think about optimisation until you've written all your code". He's saying "don't try to optimise until you know where it's needed the most". In many cases that does mean write a minimal implementation first. However in some cases knowledge, experience and early profiling will give you some pointers before that.
  - wredue 3y ago
    He also didn’t mean to write known to be shitty, slow code, and yet, we have an entire communities of programming paradigms that argue you should do just that, arguing that “premature optimization” is anything that “doesn’t feel fast enough”. What is the definition of “fast enough”? It’s impossible to tell because for those exact same people, they got their guns cocked and ready to fire a “HArDWarE is ChEApER tHAn DEvEloPErs TiMe!!!!!1!1!1!1!1!!” At you the moment you suggest that maybe needing an entire 32 core Xeon server with a tb of ram to serve 20 requests a second is MAYBE in need of optimization.
pjc50 3y ago
Telling people to "strive for balance" sounds wise but never really lands, because humans are inherently unbalanced in our desires. Everyone has different priorities.
t8sr 3y ago
The article gives some examples about Go, and lists interfaces as something you should use, because the performance cost is tiny. As someone who was formerly involved with the canonical Go style, I wanna clear up the reason why we said you shouldn't overuse interfaces. It has nothing to do with performance. (The difference between a "virtual" and "static" dispatch is not worth thinking about in Go.) It has everything to do with readability. If you return an interface, I can't figure out what happens when I call it. That's fine with something like io.Writer, because it's a good abstraction and, anyway, I can guess. But hiding business logic behind an interface is bad, because I usually should understand what happens when I do something like foo.IssueReceipt(), and if foo is an interface, then I can't really know. The rule in Go has for a long time been "return concrete values, accept interfaces" for precisely this reason. Another relevant soundbite is that Go interfaces are an "accept-side" construct, unlike Java's, which are a "declare-side" construct. This is a way of saying you shouldn't define an interface near its implementation, you should define it near where it's accepted. You might notice that this makes it really hard to do dependency injection in Go, and this, too, is intentional.
- Cthulhu_ 3y ago
  When writing code in any language, readability and maintainabilty should always trump performance. Go is fast enough, if it's slow then it's more likely you need to rethink how you're solving the problem then optimize your code. Make it work, make it pretty, make it fast, in that order. And don't optimize without measuring, another trap that many people (present company included) fall into.
  - t8sr 3y ago
    >Make it work, make it pretty, make it fast, in that order. And don't optimize without measuring, another trap that many people (present company included) fall into. This view is common nowadays, but I think people need to dial that back by maybe 30%. Too often, it's used as an excuse for software that's extremely wasteful, when with minimal tweaks it could be efficient. I am a "simplicity uber alles" kinda guy, and even I think you should add a line of code if it'll shave off half the runtime. I've heard people quote this, and the infamous Donald Knuth line, as an excuse for not knowing how to do basic things, like binary search. I've even heard people complain about caching network IO without a benchmark to show RAM is faster than DNS. Programmers, more than other people, have a tendency to take a pithy soundbite and make it their life philosophy, and I'm saying it's better not to.
gouggoug 3y ago
> Now that Go has yield, you can avoid using channels even more. I’m very confused by this statement. To my knowledge, and after a good 5 minutes search, go does not, in fact, have yield. Almost looks like an AI hallucination. edit: the post itself is tagged with “ai” while its content doesn’t mention AI at all. To me this gives credit to my theory this is an AI hallucination and this post was in part or totally generated by AI. While I’m amazed by and excited about AI, this kind of generated content makes me worried it really will contribute to the fast enshittification of the Internet.
- kmstout 3y ago
  The other post [0] tagged as "ai" doesn't either, and they're both [1] dated yesterday. --- [0] https://breadchris.com/thinkies/a-very-b-movie-plot/ https://breadchris.com/thinkies/a-very-b-movie-plot/ [1] https://breadchris.com/tags/ai/ https://breadchris.com/tags/ai/
- t8sr 3y ago
  There's an experimental feature in Go that lets you write python-like generators that work with range() and the callback is called `yield`. Here's some details: https://go.dev/wiki/RangefuncExperiment https://go.dev/wiki/RangefuncExperiment That's probably what the post is talking about. (I personally don't love this change, but now that it's clear Go 2.0 won't happen, it seems like some of the more outlandish ideas are making it into Go 1.x. Ah well.)
  - gouggoug 3y ago
    Interesting, I wasn’t aware of this experimental feature. I still think the post was AI generated. Reason being that “now that go has yield” implies this is an actual available feature of go. It’s not. And I’d find it very surprising someone would refer to an experimental feature without mentioning it’s experimental.
- Sesse__ 3y ago
  Explains why I found it so incredibly faux-deep…
rqtwteye 3y ago
One thing I have noticed that a lot of devs don't know what a profiler is and even less know how to use it. They also don't have log files that would allow analyzing where the code spends most of its time.

42 points by breadchris 3y ago

> "As creators of software and websites, we often get caught up in the never-ending pursuit of optimization. We constantly strive to make our code more efficient, our algorithms faster, and our page load times shorter." I really wish this "problem" was more common!

godelski 3y ago
There's two types of devs. Those who are constantly tripping over rabbit holes while pondering what lies inside and those who ask what a rabbit is.
- kalyantm 3y ago
  I'm completely agree with this. The people who like to dig deeper usually find structural issues that help you organise your tech debt and keep it maintainable. The other ones usually keep the ship moving forward and the product team happy, applying band-aid fixes where necessary. The key is to ensure that they are talking to each other!
  - godelski 3y ago
    > The key is to ensure that they are talking to each other! Yeah this is exactly how I see it too. You need both of these people. Even being a rabbit hole person myself, I know it is easy for us to get lost. But I think the issue is we are fewer in number and what we see isn't visible to others. But there is a deep synergy between our groups that we must balance.
- fmbb 3y ago
  And deep down at the bottom of every rabbit hole lies a Yak waiting for a barber.
- richrichie 3y ago
  Classic MBA vs PhD problem? In some domains people refuse to hire PhDs because of analysis-paralysis; they prefer the stupid MBAs who will take risks that PhDs will never take. In other, they avoid MBAs like plague because they are shallow know nothing organisms that leach on revenues.
  - I_ 3y ago
    Maybe the ultimate engineer would have an MBA and a PhD...
  - godelski 3y ago
    Both are naive. You need a balance.
  - AstralStorm 3y ago
    Thus you should hire proper BScs :)
Tabular-Iceberg 3y ago
Indeed. The only optimization I see in this industry is optimization for billable hours.
- trey-jones 3y ago
  I'm just here to provide moral support for fellow cynics. Hang in there buddy, it will all be over soon. If we're lucky.

pasc1878 3y ago

And another person finds premature Optimisation. From https://wiki.c2.com/?PrematureOptimization https://wiki.c2.com/?PrematureOptimization Premature optimization is the root of all evil -- DonaldKnuth In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "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 the root of all evil. Yet we should not pass up our opportunities in that critical 3%." Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal.

iamflimflam1 3y ago
The key part that seems to be ignored by everyone who quotes Knuth is: "Yet we should not pass up our opportunities in that critical 3%"
- n4r9 3y ago
  Exactly. He's not saying "don't think about optimisation until you've written all your code". He's saying "don't try to optimise until you know where it's needed the most". In many cases that does mean write a minimal implementation first. However in some cases knowledge, experience and early profiling will give you some pointers before that.
- wredue 3y ago
  He also didn’t mean to write known to be shitty, slow code, and yet, we have an entire communities of programming paradigms that argue you should do just that, arguing that “premature optimization” is anything that “doesn’t feel fast enough”. What is the definition of “fast enough”? It’s impossible to tell because for those exact same people, they got their guns cocked and ready to fire a “HArDWarE is ChEApER tHAn DEvEloPErs TiMe!!!!!1!1!1!1!1!!” At you the moment you suggest that maybe needing an entire 32 core Xeon server with a tb of ram to serve 20 requests a second is MAYBE in need of optimization.

pjc50 3y ago

Telling people to "strive for balance" sounds wise but never really lands, because humans are inherently unbalanced in our desires. Everyone has different priorities.

t8sr 3y ago

The article gives some examples about Go, and lists interfaces as something you should use, because the performance cost is tiny. As someone who was formerly involved with the canonical Go style, I wanna clear up the reason why we said you shouldn't overuse interfaces. It has nothing to do with performance. (The difference between a "virtual" and "static" dispatch is not worth thinking about in Go.) It has everything to do with readability. If you return an interface, I can't figure out what happens when I call it. That's fine with something like io.Writer, because it's a good abstraction and, anyway, I can guess. But hiding business logic behind an interface is bad, because I usually should understand what happens when I do something like foo.IssueReceipt(), and if foo is an interface, then I can't really know. The rule in Go has for a long time been "return concrete values, accept interfaces" for precisely this reason. Another relevant soundbite is that Go interfaces are an "accept-side" construct, unlike Java's, which are a "declare-side" construct. This is a way of saying you shouldn't define an interface near its implementation, you should define it near where it's accepted. You might notice that this makes it really hard to do dependency injection in Go, and this, too, is intentional.

Cthulhu_ 3y ago
When writing code in any language, readability and maintainabilty should always trump performance. Go is fast enough, if it's slow then it's more likely you need to rethink how you're solving the problem then optimize your code. Make it work, make it pretty, make it fast, in that order. And don't optimize without measuring, another trap that many people (present company included) fall into.
- t8sr 3y ago
  >Make it work, make it pretty, make it fast, in that order. And don't optimize without measuring, another trap that many people (present company included) fall into. This view is common nowadays, but I think people need to dial that back by maybe 30%. Too often, it's used as an excuse for software that's extremely wasteful, when with minimal tweaks it could be efficient. I am a "simplicity uber alles" kinda guy, and even I think you should add a line of code if it'll shave off half the runtime. I've heard people quote this, and the infamous Donald Knuth line, as an excuse for not knowing how to do basic things, like binary search. I've even heard people complain about caching network IO without a benchmark to show RAM is faster than DNS. Programmers, more than other people, have a tendency to take a pithy soundbite and make it their life philosophy, and I'm saying it's better not to.

gouggoug 3y ago

> Now that Go has yield, you can avoid using channels even more. I’m very confused by this statement. To my knowledge, and after a good 5 minutes search, go does not, in fact, have yield. Almost looks like an AI hallucination. edit: the post itself is tagged with “ai” while its content doesn’t mention AI at all. To me this gives credit to my theory this is an AI hallucination and this post was in part or totally generated by AI. While I’m amazed by and excited about AI, this kind of generated content makes me worried it really will contribute to the fast enshittification of the Internet.

kmstout 3y ago
The other post [0] tagged as "ai" doesn't either, and they're both [1] dated yesterday. --- [0] https://breadchris.com/thinkies/a-very-b-movie-plot/ https://breadchris.com/thinkies/a-very-b-movie-plot/ [1] https://breadchris.com/tags/ai/ https://breadchris.com/tags/ai/
t8sr 3y ago
There's an experimental feature in Go that lets you write python-like generators that work with range() and the callback is called `yield`. Here's some details: https://go.dev/wiki/RangefuncExperiment https://go.dev/wiki/RangefuncExperiment That's probably what the post is talking about. (I personally don't love this change, but now that it's clear Go 2.0 won't happen, it seems like some of the more outlandish ideas are making it into Go 1.x. Ah well.)
- gouggoug 3y ago
  Interesting, I wasn’t aware of this experimental feature. I still think the post was AI generated. Reason being that “now that go has yield” implies this is an actual available feature of go. It’s not. And I’d find it very surprising someone would refer to an experimental feature without mentioning it’s experimental.
Sesse__ 3y ago
Explains why I found it so incredibly faux-deep…

rqtwteye 3y ago

One thing I have noticed that a lot of devs don't know what a profiler is and even less know how to use it. They also don't have log files that would allow analyzing where the code spends most of its time.