3 ms·
I'd go further and say that readability and/or ease of use _often_ trumps efficiency. I/O tends to be the bottleneck at least as often as CPU, apart from anythi
by pmccool 17y ago
I'd go further and say that readability and/or ease of use _often_ trumps efficiency. I/O tends to be the bottleneck at least as often as CPU, apart from anything else.
I agree with the point about writing in assembly language. This rant is basically arguing for speculatively micro-optimising _every line of code_ by choosing a supposedly faster language.
- scumola 17y agoI'm the author of the original post. The article isn't about optimizing every line of code, it's about not being lazy and choosing a language that you might have to do a little more work in for a massive decrease in bloat and execution time. One tool isn't always the right one for every problem. Don't use a hammer to screw in a screw. Sure, the screw will go in, but with just a little more effort (using a screwdriver) the task will be done much better. It's about wasting money & resources because a programmer doesn't want to write a little extra code to manage memory or watch return codes.
- pmccool 17y agoI'll put it another way. Most code isn't performance-critical. If you choose to write everything in, say, assembler, most of it will give you little or no gain. Assembler's harder to write than Java, so every line is costing you money, whether it actually runs faster or not. The _effect_ is the same as speculatively optimising every line: substantial cost, uncertain benefit, potential to introduce bugs, etc etc.