5 ms·

This x 10000 ! If I had a dime for every time I provided this exact feedback in code reviews…I find surprising that a lot of devs in tech industry are obsessed

This x 10000 ! If I had a dime for every time I provided this exact feedback in code reviews…I find surprising that a lot of devs in tech industry are obsessed with pointless micro optimizations and they don’t care about writing maintainable, testable simple code. My final comment is always to not outsmart compilers/jvm because they tend to do a much better job that developers. Please, don’t optimize unless you have reasons to do so and numbers backing that up.

dahfizz 4y ago
It depends on your specialization, I guess. If you're making a website, a few microseconds here and there probably don't matter. But in my field (Fintech), performance really does matter. Doing the simple, slow thing is just lazy and won't make it through review.
- imron 4y ago
  Great. Should be easy to prove then.
  - dahfizz 4y ago
    Yup, we have a good benchmarking suite to make sure changes don't cause regressions and that optimization changes actually work. That said, I think asking a developer to write everything they do twice so that they can A/B test is overboard. You can come back and really aggressively optimize later, but I think the "default" should be the fast thing, rather than the slow & easy thing.
    - bmacho 4y ago
      If "performance really does matter" (in Fintech) then a developer surely can write everything twice or more.
      - dahfizz 4y ago
        We could, yeah. I'm sure you're capable of re-writing everything you do twice. It's just a huge waste of time. You get just as much benefit by assigning a performance refactor to an engineer when needed vs literally halving or worse the whole teams productivity.
      - gpderetta 4y ago
        Time to market can matter in fintech as much as anywhere else. Edit: also optimizations often interact with each other and you can't always benchmark all possible combinations, so sometime you do have to rely on experience or reasoning from first principles to decide if an optimisation is worth it or not.
    - elimerl 4y ago
      The idea is that the "default" is the easy thing, which is usually optimized by the compiler.
      - TillE 4y ago
        When you're writing in a language like Rust or C++, you know broadly what the compiler optimizes and what it probably won't. You do need to do the work yourself a lot of the time.
ok123456 4y ago
This is true for application code. But, Rust is trying to sell itself as a systems language and an embedded language and a language you can write kernel modules in. Memory budget matters in these cases.
- tialaramex 4y ago
  If memory budget matters, you have a memory budget. So you should be measuring and you can actually tell where you need improvements. But in practice what we see overwhelmingly is that people want to do this stuff but they aren't measuring, because measuring is boring whereas making the code more complicated to show off how much you think you know about optimisation is easy. Knock it off.
  - ok123456 4y ago
    Then knock off trying to use Rust as a systems language. Linear types make refactoring this nearly impossible if it does become and issue.
    - tialaramex 4y ago
      Works really nice for me, of course, I actually measure what I'm doing. You edited your comment, so I guess I will too: Rust doesn't actually have Linear types. Linear types ("must use or compile error") would be tricky to provide, Aria blogged about it back in the day. So that's definitely going to be a problem with your refactoring.
josephg 4y ago
My advice is the opposite: if you want to make performance justifications for code, you need a benchmarking suite. I have them for a lot of my projects. (Rust’s criterion is a delight). A good benchmark suite is a subtle thing to write - you want real world testing data, and benchmarks for a range of scenarios. The benchmarks should be run often. For some changes, I‘ll rerun my benchmarks multiple times for a single commit. I benchmark the speed of a few operations, serialisation size, wasm bundle size and some other things. Having real benchmarking data is eye opening. It was shocking to me how much the wasm bundle size increased when I added serialisation code. The time to serialise / deserialise a big chunk of data for me is 0.5ms - so fast that it’s not worth more microoptimizations. Lots of changes I think will make the code slower have no impact whatsoever on performance. And my instincts are so often wrong. About 50% of microoptimizations I try either have no effect or make the code slightly slower. And it’s quite common for changes that shouldn’t change performance at all to cause significant performance regressions for unexpected reasons. I’ve also learned how important “short circuit” cases can be for performance. Adding a single early check for the trivial case in a function can sometimes improve end to end performance by 15-20%, which in already well tuned code is massive. Performance work is really fun. But if you do performance tuning without measuring the results, you’re driving blindfolded. You’re as likely to make your code worse as you are to make it better. Add benchmarks.

dahfizz 4y ago

It depends on your specialization, I guess. If you're making a website, a few microseconds here and there probably don't matter. But in my field (Fintech), performance really does matter. Doing the simple, slow thing is just lazy and won't make it through review.

imron 4y ago
Great. Should be easy to prove then.
- dahfizz 4y ago
  Yup, we have a good benchmarking suite to make sure changes don't cause regressions and that optimization changes actually work. That said, I think asking a developer to write everything they do twice so that they can A/B test is overboard. You can come back and really aggressively optimize later, but I think the "default" should be the fast thing, rather than the slow & easy thing.
  - bmacho 4y ago
    If "performance really does matter" (in Fintech) then a developer surely can write everything twice or more.
    - dahfizz 4y ago
      We could, yeah. I'm sure you're capable of re-writing everything you do twice. It's just a huge waste of time. You get just as much benefit by assigning a performance refactor to an engineer when needed vs literally halving or worse the whole teams productivity.
    - gpderetta 4y ago
      Time to market can matter in fintech as much as anywhere else. Edit: also optimizations often interact with each other and you can't always benchmark all possible combinations, so sometime you do have to rely on experience or reasoning from first principles to decide if an optimisation is worth it or not.
  - elimerl 4y ago
    The idea is that the "default" is the easy thing, which is usually optimized by the compiler.
    - TillE 4y ago
      When you're writing in a language like Rust or C++, you know broadly what the compiler optimizes and what it probably won't. You do need to do the work yourself a lot of the time.

ok123456 4y ago

This is true for application code. But, Rust is trying to sell itself as a systems language and an embedded language and a language you can write kernel modules in. Memory budget matters in these cases.

tialaramex 4y ago
If memory budget matters, you have a memory budget. So you should be measuring and you can actually tell where you need improvements. But in practice what we see overwhelmingly is that people want to do this stuff but they aren't measuring, because measuring is boring whereas making the code more complicated to show off how much you think you know about optimisation is easy. Knock it off.
- ok123456 4y ago
  Then knock off trying to use Rust as a systems language. Linear types make refactoring this nearly impossible if it does become and issue.
  - tialaramex 4y ago
    Works really nice for me, of course, I actually measure what I'm doing. You edited your comment, so I guess I will too: Rust doesn't actually have Linear types. Linear types ("must use or compile error") would be tricky to provide, Aria blogged about it back in the day. So that's definitely going to be a problem with your refactoring.

josephg 4y ago

My advice is the opposite: if you want to make performance justifications for code, you need a benchmarking suite. I have them for a lot of my projects. (Rust’s criterion is a delight). A good benchmark suite is a subtle thing to write - you want real world testing data, and benchmarks for a range of scenarios. The benchmarks should be run often. For some changes, I‘ll rerun my benchmarks multiple times for a single commit. I benchmark the speed of a few operations, serialisation size, wasm bundle size and some other things. Having real benchmarking data is eye opening. It was shocking to me how much the wasm bundle size increased when I added serialisation code. The time to serialise / deserialise a big chunk of data for me is 0.5ms - so fast that it’s not worth more microoptimizations. Lots of changes I think will make the code slower have no impact whatsoever on performance. And my instincts are so often wrong. About 50% of microoptimizations I try either have no effect or make the code slightly slower. And it’s quite common for changes that shouldn’t change performance at all to cause significant performance regressions for unexpected reasons. I’ve also learned how important “short circuit” cases can be for performance. Adding a single early check for the trivial case in a function can sometimes improve end to end performance by 15-20%, which in already well tuned code is massive. Performance work is really fun. But if you do performance tuning without measuring the results, you’re driving blindfolded. You’re as likely to make your code worse as you are to make it better. Add benchmarks.