3 ms·

Well okay, but guess which one I'd rather have to maintain in a big codebase? Clearly written by a theoretical engineer.

by sm4sh 5y ago

humblepie 5y ago
For a large codebase, this would be encapsulated and heavily commented, etc. It's something that you pull out when you need to make something "go to eleven" kind of thing.
- raldi 5y ago
  Exactly. You could have some exhaustive unit tests as well, and after that there would be nothing to maintain.
teachingassist 5y ago
Plenty of library functions are already going to be optimised in this type of way - just because they're not visible in your codebase doesn't mean they are not there.
Forge36 5y ago
It's about use cases. There was an old lady 6 about unoptimized behavior in VB6 and why is wasn't necessary to do so. I had to write a wrapper for it which was optimized in my code. Was it harder to read? Yes. Did it produce a significant performance improvement? Also yes. Software development is about tradeoffs. Demoing one way to improve a simple function helps others trunk how they write code, and more importantly why they wrote specific code
JKCalhoun 5y ago
I've worked with engineers that must read these blogs and try to out-clever everyone. They succeed, and that's the problem.
deleted 5y ago
[deleted]
commandlinefan 5y ago
> rather have to maintain Well, as long as it works, what difference does it make? As long as it's prefixed with a // This compares the matching number of bytes comment, you should never have to mess with it.
- rocqua 5y ago
  With a compiler or architecture change, I guess this could create awkward to handle performance regressions.
rocqua 5y ago
So if your big codebase were profiled, and the 99th percentile case happened to spend 80% of its time in this function, you would still stick to the old function unwaveringly? Even if your system was latency sensitive, and your 99 percentile spikes were far from acceptable? Sure, there are many cases where this is a premature optimization. This blog never said otherwise. But that doesn't mean there is never a time for optimization. And if profiling points at this, then this speedup can be valuable.

Well okay, but guess which one I'd rather have to maintain in a big codebase? Clearly written by a theoretical engineer.

by sm4sh 5y ago

Well okay, but guess which one I'd rather have to maintain in a big codebase? Clearly written by a theoretical engineer.

humblepie 5y ago

For a large codebase, this would be encapsulated and heavily commented, etc. It's something that you pull out when you need to make something "go to eleven" kind of thing.

raldi 5y ago
Exactly. You could have some exhaustive unit tests as well, and after that there would be nothing to maintain.

teachingassist 5y ago

Plenty of library functions are already going to be optimised in this type of way - just because they're not visible in your codebase doesn't mean they are not there.

Forge36 5y ago

It's about use cases. There was an old lady 6 about unoptimized behavior in VB6 and why is wasn't necessary to do so. I had to write a wrapper for it which was optimized in my code. Was it harder to read? Yes. Did it produce a significant performance improvement? Also yes. Software development is about tradeoffs. Demoing one way to improve a simple function helps others trunk how they write code, and more importantly why they wrote specific code

JKCalhoun 5y ago

I've worked with engineers that must read these blogs and try to out-clever everyone. They succeed, and that's the problem.

deleted 5y ago

[deleted]

commandlinefan 5y ago

> rather have to maintain Well, as long as it works, what difference does it make? As long as it's prefixed with a // This compares the matching number of bytes comment, you should never have to mess with it.

rocqua 5y ago
With a compiler or architecture change, I guess this could create awkward to handle performance regressions.

rocqua 5y ago

So if your big codebase were profiled, and the 99th percentile case happened to spend 80% of its time in this function, you would still stick to the old function unwaveringly? Even if your system was latency sensitive, and your 99 percentile spikes were far from acceptable? Sure, there are many cases where this is a premature optimization. This blog never said otherwise. But that doesn't mean there is never a time for optimization. And if profiling points at this, then this speedup can be valuable.