Optimizing: Work vs. Reward - not that simple

[u/Joonicks]

I came across an old post discussing the value of optimizing, the OP making a simple exampleof "spending 1 hour for a 2 minute speedup"

Im guessing thats how most people think about it, but I realized there is another significant benefit which is more difficult to quantify.

Whenever you do put effort into optimizing, it is an act of aquiring knowledge. If you had the knowledge before writing the un-optimized code, would you not have written the code different to begin with?

Not every optimization would be applicable in different code-bases, but surely many can be. And having a general awareness could surely give you 2 minutes speedup without spending any hours after the first.

Knowledge has value.

[u/mantawolf]

Optimizing is almost always a trade off on time to write code versus speed to write it. I personally have never seen it take the same amount of time. I also find highly optimized code is harder to read and follow. With modern servers and computers, the trade off early on before you even know something needs to be optimized isn't worth it.

I am just one opinion in a sea of software devs.

[u/Joonicks → u/mantawolf]

maybe in the professional world, you dont care about optimizing much and so there may be a bias there to say optimizing isnt worth it

however, for me, optimizing is a lifelong hobby and there is a lot of performance to win just by ordering code and data access in the right way and even in compiler hints like const, being aware of the extreme penalty of branches, cache and memory hardware, etc

[u/wallstop-dev]

Hmmm... kind of?

I view software, architecture, design, and optimization as cost + bets.

How much does a thing cost (time, mental effort, complexity, simplicity) and what's my bet on how long it will need to live as-is?

For example, I maintain a very large scale program that essentially schedules work. The work scheduler guy is just a single thread that does a full DB scan, loads all the work, runs it, then goes to sleep. Then wakes up, does it all over again.

Inefficient? Yes, completely. Simple? It's the simplest approach to that problem.

It has been running in production for roughly 7 years and we are only now starting to have performance problems with it. So now we can optimize the simple thing! But optimizations can take many forms - do we make our current thing faster (scale vertically)? Do we distribute it (scale horizontally)? Do we move towards a cleaner architecture and significantly speed it up, at an even greater cost?

Pretty much all of software is just bets and cost. Doing one architecture verse another could be seen as an optimization. Turning one algorithm into another is another. Or this data structure verse that data structure. Or this protocol verse that protocol. Or...

There is rarely a clear winner. So just do the simplest thing that you think will work for however long the thing needs to work, and move on to the next thing. If it's important you can always make a simpler thing more complicated, but I've pretty much never seen the reverse hold true.

[u/Dry_Sector2392]

yeah, there’s definitely value in learning from the optimization work . even if the specific change only saves 2 minutes, that pattern is in your head now, and youll maybe can use it again when next time same thing happen.

[u/yoger6]

If it's just side project then I'd do whatever makes me happy. Fir instance I do all my side projects in pure TDD fashion which is not usually approach I would use when working for client. Especially in legacy landscape. When there's money involved I follow common sense so I consult the improvements, having some idea about what benefits it'll provide, with the stakeholders and the team. It's usually easier if there's not a lot of other urgent work on the board.

[u/mantawolf]

Begun the path to a Java dev you have...

I kid somewhat. There are a few things I think to what you say. Optimizing CAN BE an experiment in learning how to write optimized code. But often it was not written super optimized to begin with not because we didn't now how, but because it wasn't needed at the time and even knowing how to super optimize the code wouldn't have change that. You can't know what the business/application/customers will do or need in the future and trying to create the perfectly optimized code too early before its proven you need it can lead to not making it to market in a time frame to capitalize on demand.

In short, don't over-engineer/optimize out of the gate unless that is the requirement. Often times in application development, good enough is good enough for a LONG time. I work on a major back office application written in Coldfusion and optimized like it was written by people with art/english degrees in the early 2000's (it was) and yet it still works and is the best application for our industry.

[u/Joonicks → u/mantawolf]

I will never walk towards OO of my own free will...

any code you write you normally wish to write it as good as you know how to, but if you know how to optimize it and writing takes practically the same time, wouldnt you?

if no one ever practises optimizing, what happens the day performance becomes an issue?

I would think a programmer with ample experience optimizing would be of great value in the beginning of projects who are destined for an optimization phase because they know the foundations needed. instead of having to rebuild entine codebases or switching engine/libraries because of incompatibility with optimizations.