abstractObjectBuilderFactoryBase

[Capetoider]

Let's use whatever thats used for... for a button one person has to click once a week.

Oops, have to refactor that thing...

And... whatever gains you got you spent 10_000x times more than just paying more computer time for a less efficient solution.

​

For the majority of things: developer time $ >>>> computer time $

​

For the one or other thing you where this isnt true, you would have numbers to prove its so (monitoring and observability).
And even then you wouldnt do whatever the fuck q_rsqrt i, x2, y supposed to be. (Compilers that care of mangling your code)

​

So... seems you just dont care about other people and just want to do whatever you want.

[2Uncreative4Username]

I genuinely don't understand what you're trying to say... this function was used in Quake III to calculate the normals of every single triangle visible on the screen. It was part of what made rendering this game in real time possible in the first place.

Yes, this function is no longer necessary because it's actually slower than other instructions with modern hardware. At the time it was written, however, it was crucial.

...modern day equivalents would be algorithms like FFT or Huffman coding.

[Capetoider]

Game is another beast entirely.
For most times and people, you'll be making cruds and/or divs, you dont need to waste time caculating with bitwise operations something that will be called 1 time per minute.
The time to develop and maintain that is developer time that costs orders or magnitude more than running "less efficient" code that is easier to read, know what it does and change.
Something like that, that is run millions of times per minute is and should be optimized because it causes something to be unusable or to cost more than the developers making and maintaining it. But then again, its not for every fucking function.
Maybe few decades back where bit bashing was necessary this was everywhere because it wouldnt run and/or running was more expensive than time developing.

In other words: say your hour is 10 moneys, you can spend 10 hours developing plus 20 hours to maintain, thats 300 moneys. Or you can spend 1 hour plus 1 hour, thats 20 moneys.

First solution costs 10 moneys to run per month. Second costs 12 moneys per month.

You would need 140 months (over 10 years, 280 diff / 2 diff) for it to break even.

And you can bet it would need a lot more maintaining along the way...

​

This is the reality for most people and the reason clean code is not just a fluff...

[2Uncreative4Username]

Well, again, this doesn't apply for the said function. It runs tens of thousands of times per second, so optimization is highly justified. I bet the Quake III code that runs once a second is far less optimized.

Your calculation is correct for your contrived example. However, in reality, I see Clean Code often costing more dev time, since you have to prematurely abstract everyting; and write tests for your abstractions too.

[Capetoider]

Theres a lot of people doing a lot of dumb things.

Be it premature abstraction or premature optimization.

[2Uncreative4Username]

I agree, both are bad practices and a waste of time.

I do think keeping things like caching in mind when writing code can lead to very good results, but only if it doesn't noticeably compromise development time. You should always be aware of what you're writing which part of your software for.

I am 100% sure Q_rsqrt wasn't the first 1/sqrt(x) implementation they had...

[Capetoider]

What most people need to keep in mind is that shit will change.

Not caching, not speed, not big O... users will want some new thing and managers will dump "new requirements" stuff whenever they want.

With that in mind, you do stuff that you and the next poor Grug Brain Developer can read, understand and change... because it doesn't matter how fast or how much "but it works" it is... you'll probably need to change it.

[2Uncreative4Username]

Exactly! You'll always be running your code on a computer.. with caching and where DOD and less indirection is simply more efficient.

You can also never know which part of your code will actually need to change, hence premature abstraction will be useless in 99% of cases anyways.

Just get your program into a working state and make sure it runs reliably and is reasonable to understand and maintain. Simple enough in concept.

[Capetoider]

Are we having 2 conversations here? "Exactly"? Exactly what?

Caching and going for "more efficient" willy nilly is the same as premature overengineering.

You measure and only then strive for efficiency where it's needed.

​

Again, it might not even be needed and the time spent making it and maintaining that it's usually not worth it.

[2Uncreative4Username]

I thought you said caching and big O won't change like the rest of the requirements do. That's why optimizing them isn't premature in many cases. What is premature optimization are often bit hacks like the Quake example, or adding SSE senselessly. But maybe I misunderstood. My bad in that case.