Timeline for When is optimization not premature and therefore not evil?
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Jan 4, 2016 at 3:51 | history | edited | Robert Harvey | CC BY-SA 3.0 |
deleted 9 characters in body
|
| Oct 6, 2015 at 13:09 | comment | added | Olof Forshell | Who says that "painless" optimizations always result in "code obfuscation"? There are far too many "never" and "always" in these comments. Programming is a grey area and noone can say that A or B is always or never a good solution. | |
| S Jun 15, 2015 at 21:07 | history | suggested | Deduplicator | CC BY-SA 3.0 |
typo-fix and minimal formatting improvement
|
| Jun 15, 2015 at 20:15 | review | Suggested edits | |||
| S Jun 15, 2015 at 21:07 | |||||
| May 13, 2014 at 1:54 | comment | added | supercat |
@sbi: I only use the division or remainder operators if there is some reason why I need to those it rather than a shift or bitmask, perhaps because shift and bitmask operators will in most implementations give the results I need with positive or negative divisors, while / and % will add extra code bloat adjusting the results to be wrong, and necessitate the use of extra code bloat to set it right. Rather than worry about whether / or % will work correctly, it's easier to just use >> and &. If there were operators that behaved like / and % for Euclidian division, I'd use those
|
|
| Mar 15, 2012 at 13:31 | comment | added | Spencer Rathbun | All of these involve could be restated as "X facts show that Y is better than Z in some non-trivial manner. Therefore, let us use Y instead of Z." This is the same as not prematurely optimizing, you just didn't need to find the facts, since you already have them. | |
| Jan 14, 2011 at 5:22 | comment | added | Loren Pechtel | I can't imagine not knowing the bit shift operators for any language. Sure, i / 2 is generally clearer but now and then you're really working at the bit level and thus the bit shift operators are actually clearer. | |
| Jan 14, 2011 at 1:04 | comment | added | Ken Bloom | You said "Basically, some varieties of 'painless' optimizations simply aren't ... worth the code obfuscation." The thing people need to understand is that code obfuscation isn't painless. | |
| Jan 2, 2011 at 20:23 | comment | added | sbi |
@Matthew: Teach them what? Dirty and unnecessary tricks? Why? If profiling shows that a i/2 is indeed a hot spot and that (unbelievable, but let's assume) i>>1 makes it faster, so do it, and put a comment to it that this profiling showed that this is faster. If this is indeed needed anywhere (which I doubt, since, as Matthieu said, compilers should be smart enough to do this themselves), novices will learn something, if it isn't (which is likely), why do you want to plug their heads with unneeded folklore?
|
|
| Jan 2, 2011 at 14:18 | comment | added | Matthew Whited |
To the comment over i/2 versus i>>1... this would be a good chance to teach junior devs something instead of just coding to the least common denominator.
|
|
| Jan 1, 2011 at 23:09 | comment | added | Benbob |
Generally things like which framework or database to work with make the most difference. The higher level decisions, the ones you cannot change later on, are more important. Always benchmark/profile before you do any optimizations and stop when you reach the goal. Smaller optimizations like chaning i++ to ++i make about as much difference as a drop in a swimming pool. First plant the right tree (language, framework stack) then pick the lowest hanging fruits first. Or just shake the tree :)
|
|
| Jan 1, 2011 at 21:54 | vote | accept | Gaurav | ||
| Jan 1, 2011 at 21:40 | history | edited | BlairHippo | CC BY-SA 2.5 |
added 574 characters in body
|
| Jan 1, 2011 at 21:33 | comment | added | BlairHippo | @Matthieu M. / @Steve314: An excellent point, and one I hadn't considered. I'll integrate it into the answer. | |
| Jan 1, 2011 at 19:42 | comment | added | Larry Coleman | @Matthieu: That is a much better example. You should make an answer out of it. | |
| Jan 1, 2011 at 19:29 | comment | added | Matthieu M. |
@Larry: I have been doing C++ almost exclusively for the past 3 years (with some Python and an introduction to Haskell), nonetheless even if you do know the effect of the shift operators or of bit masking, it does obfuscate the code somewhat, to use i & ~(unsigned int)1 when one simply wants i - i%2 (that is, the greatest even number inferior or equal to the current number) or that kind of things. Of course, you can always wrap this up in an inline function with a meaningfull name, but unless inspecting the assembly / measuring shows a difference... I would not bother.
|
|
| Jan 1, 2011 at 17:33 | comment | added | Larry Coleman | @Matthieu and Joris: If you're doing C# or Java coding, I guess it's understandable not to know the logical shift operators. The libraries for both are so big that one person cannot possibly know them all, so why bother learning operators you won't have any reason to use? | |
| Jan 1, 2011 at 17:17 | comment | added | Bart van Ingen Schenau | In my view, optimisations, even simple ones, should also be regarded evil if they impact readabiliy/maintainabiliy of the code and are not based on actual performance measurements. | |
| Jan 1, 2011 at 16:55 | comment | added | Matthieu M. | @Larry: Not off the top of my head, sorry, but I can guarantee you I have colleagues who would make a double take on this. | |
| Jan 1, 2011 at 15:01 | comment | added | Joris Meys | @Larry : I didn't, so I guess it's a good example. | |
| Jan 1, 2011 at 14:46 | comment | added | Larry Coleman | @Matthieu: I understood i >> 1 right away. Do you have a better example? | |
| Jan 1, 2011 at 13:53 | comment | added | Matthieu M. |
I agree with Steve here, sometimes the "optimization" is simply not worth it, especially because compilers are so damn good. Example ? if i is unsigned, i / 2 can be replaced by i >> 1. It is faster. But it is also more cryptic (not everyone will see the effect, even those who do may lose time). But the worst of it is that the compiler will do it anyway, so why obfuscate the source code ;) ?
|
|
| Jan 1, 2011 at 12:03 | comment | added | user8709 | Occasionally, solving a phantom problem easily is still mildly evil, as it can result in harder to read, harder to maintain code. Not much harder (or it wouldn't be an easy solution), but perhaps occasionally still relevant. An example might be using a clever bitwise trick that some people won't recognise, and which the compiler will probably apply anyway if it's useful. | |
| Jan 1, 2011 at 7:45 | history | answered | BlairHippo | CC BY-SA 2.5 |