Hacker News new | comments | show | ask | jobs | submit login

Well, thats a problem you can see a lot these days. People just throwing software together without thinking about the efficiency anymore. Because "We'll scale it in the cloud". I'm wondering how much energy and money could be saved by just having efficiency in mind again.



Recently I found out that in Rust you can not only mark a function as `[test]`, but also `[bench]` out of the box (everything included in the base distribution). This can be run automatically on every cargo build, so people actually see the result. (in time per execution and optionally data throughput) I think that's a great way of improving visibility of the performance issues.

Many people are happy to play for internet points, whether they're SO points, number of patches submitted, bugs fixed, or something else. I'd be really happy if performance was one of the games they can play.


That isn't really a problem. The problem is that people never pause and reflect over it once they reach some critical adoption. OPs software might never have been a productive business if he micro optimized some C++ code in pursuit of best possible performance. Make it work, then make it fast if you need to, but only if you need to.


As Dewie also pointed out, it is about keeping performance and efficiency in mind when programming and not about squeezing out the last drop of performance before going live. Not thinking about it from the start will cause a lot of trouble in the long run and might make the transition to something more efficient quite painful or "impossible".


> OPs software might never have been a productive business if he micro optimized some C++ code in pursuit of best possible performance.

It's not an either-or. Maybe the best long-term approach would be to write it in a high-level style favouring readability, productivity and adaptiveness, while also being conscious not to use features that could lead to performance problems. Maybe you'd write it in a compiled (native/efficient VM) language[1] with garbage collection and be mindful of memory layout, instead of writing it in Ruby[2]and then having to rewrite some parts in another generally faster language later. Then you also wouldn't have to have that "Ugh, now I need to bust out C++/C/Go/Whatever and rewrite that stuff... oh never mind it's probably fast enough" when you start to run into performance problems.

[1] More precisely an implementation of a language which is compiled...

[2] Though maybe Ruby is compiled in the canonical implementation, for all I know.


10/10, would agree again.


What Herb Sutter calls premature pessimization.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: