in reply to The Rules of Optimization Club

While code simplicity and clarity normally trump efficiency, efficient idioms should routinely be preferred to inefficient ones whenever code maintainability does not suffer. Knowing and understanding the efficiency of basic language constructs is part of mastering a programming language.

Alexandrescu and Sutter (C++) for example, in Guideline 9, "Don't pessimize prematurely", advise you to prefer efficient idioms to less efficient ones whenever the choice is arbitrary. This is not premature optimization rather it is the avoidance of gratuitous pessimization. Sometimes, as with i++ versus ++i, or passing objects by value versus const reference, the more efficient alternative is no harder to read and maintain. Even better, declaring objects at point of first use, for instance, the more efficient idiom also improves code maintainability.

Replies are listed 'Best First'.
Re^2: The Rules of Optimization Club
by educated_foo (Vicar) on Mar 31, 2012 at 04:00 UTC
    Knowing and understanding the efficiency of basic language constructs is part of mastering a programming language.
    This. The "methodology" of writing whatever arbitrarily-inefficient code you first think of that produces the desired output, then doing a bunch of profiling followed by tweaking and/or extensive rewrites, is a blight. If you write something both readable and reasonably efficient in the first place, there's a good chance you won't have to mess with it later. Having a clue about hardware and data structures really pays.

    This, by the way, is why I've always been annoyed by the "ArrayList" in Java (don't get me started on the "HashArrayListWhatever" used in Lua): depending on your expected access patterns, you'll want either an array or a list. In some cases, you'll want something fancier or more specialized. Arrays give you fast random access and slower insertions; doubly-linked lists give you fast insertion and slower random access; singly-linked lists give you fast insertion at one end with minimal space overhead; balanced trees scale well for most operations, but have a significant constant penalty. If you start out with the right data structure, you may not have to bother with laborious profile-guided optimization.

[reply]

In Section Meditations