3 ms·

I've always thought it meant: Simplicity + Readability >>> performance If I can look at a method and think of obvious speedups then it was a good method becau

by sjducb 4y ago

I've always thought it meant: Simplicity + Readability >>> performance If I can look at a method and think of obvious speedups then it was a good method because I could easily read it and be confident about what it does. Loads of performant code is really hard to read because it's full of magic that speeds things up. When you try to modify this code you're never sure if you need to keep the "performance" especially if there's no performance test. I've also done speedups of legacy software. What you find is that most of it is "basically instant" and one method takes 5min. You rewrite that method to be fast, add a performance test to keep it fast, and a big comment explaining exactly why it needs to be fast and how it works.

GuB-42 4y ago
> Loads of performant code is really hard to read because it's full of magic that speeds things up. That's if you go down to the lowest levels of optimization. The kind of things you see in compression, hashing, sorting, codecs,... Really hardcore optimization because otherwise, you wouldn't be able to watch that video at without turning your device into an heater, if at all. But in more reasonable cases, simpler code often turns out faster. The less you do, the faster it runs, which is kind of obvious. Readable code is also a good thing for performance, if is easier to see and fix inefficiencies if the code is readable. A good part of performance problems are simply bugs: memory leaks, operations done several times for no reason, etc... and many others are fixable with no loss in readability, for example by using the proper data structure. As for the last part, use a profiler, there is no point optimizing without a profiler. If you don't have a profiler, then good luck, it is doable, like investigating a crash without a stack trace is doable, but it is horrible. One thing I do no matter what: always use the algorithm with the best big-O complexity available, unless you have a good reason not to. You may think you don't have enough data for that O(N^2) or worse to matter, but it can change, in fact, this is the most common type of change, and once you get in the zone, it can get really slow really fast, lookup "accidentally quadratic".
trashtester 4y ago
> If I can look at a method My resistance to the term "Premature optimization" is generally not about optimizing single methods, but usually either about optimizing how to split an application up to modules (services, classes methods) or about what technology to use for each component. For instance, if you have an "inner loop" or basic computation unit that requires you to do several REST requests to other services (serially, with little room for parallelism) where it would have been possible to maintaina few hashmaps locally in your service with the same data, you may easily take processing time from 1 hour to 1 week for some computation task. With some experience, you should be perfectly capable of undersanding this way before defining how to split your workloads up into microservices.

by sjducb 4y ago

GuB-42 4y ago

> Loads of performant code is really hard to read because it's full of magic that speeds things up. That's if you go down to the lowest levels of optimization. The kind of things you see in compression, hashing, sorting, codecs,... Really hardcore optimization because otherwise, you wouldn't be able to watch that video at without turning your device into an heater, if at all. But in more reasonable cases, simpler code often turns out faster. The less you do, the faster it runs, which is kind of obvious. Readable code is also a good thing for performance, if is easier to see and fix inefficiencies if the code is readable. A good part of performance problems are simply bugs: memory leaks, operations done several times for no reason, etc... and many others are fixable with no loss in readability, for example by using the proper data structure. As for the last part, use a profiler, there is no point optimizing without a profiler. If you don't have a profiler, then good luck, it is doable, like investigating a crash without a stack trace is doable, but it is horrible. One thing I do no matter what: always use the algorithm with the best big-O complexity available, unless you have a good reason not to. You may think you don't have enough data for that O(N^2) or worse to matter, but it can change, in fact, this is the most common type of change, and once you get in the zone, it can get really slow really fast, lookup "accidentally quadratic".

trashtester 4y ago

> If I can look at a method My resistance to the term "Premature optimization" is generally not about optimizing single methods, but usually either about optimizing how to split an application up to modules (services, classes methods) or about what technology to use for each component. For instance, if you have an "inner loop" or basic computation unit that requires you to do several REST requests to other services (serially, with little room for parallelism) where it would have been possible to maintaina few hashmaps locally in your service with the same data, you may easily take processing time from 1 hour to 1 week for some computation task. With some experience, you should be perfectly capable of undersanding this way before defining how to split your workloads up into microservices.