blog: Overlooked Essentials for Optimizing Code

[Bruno Medeiros]

On 10/09/2010 19:20, Walter Bright wrote:
> http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/
>

Generally, an interesting article. However, there are a few points I 
would like to counter:

"Nope, it isn't avoiding premature optimization. It isn't replacing 
bubble sort with quicksort (i.e. algorithmic improvements). It's not 
what language used, nor is it how good the compiler is. It isn't writing 
i<<2 instead of i*4.

It is:

    1. Using a profiler
    2. Looking at the assembly code being executed
"

There is a bit confusion here. The first things (use algorithmic 
improvements, a better language or compiler, "i << 2" code, etc.) are 
not of the same nature as the other things (1 & 2 - Using a profiler and 
looking at the assembly )
The first are techniques for optimizing particular code, and the second 
ones are strategies for figuring out *which* code is best to try to 
optimize. It does not make sense to try to oppose the two, because the 
second one actually requires the first one to be useful. I mean, no code 
has ever improved in performance *strictly just* by using a profiler or 
looking at the assembly code being executed. :)


But more importantly 1 and 2, (especially 1: "using a profiler") are 
crucial elements of "avoiding premature optimization". I mean, I learnt 
"avoid premature optimization" as being "don't optimize code until you 
*know* that code is a bottleneck", and in something like 80% of the 
books/articles/college-courses that taught about premature optimization, 
they also explicitly mentioned that running a profiler was by far the 
best way to determine which code is the bottleneck, and that the 
alternative of guessing is bad, because it is often wrong.



"Though that is undeniably true, there are two caveats that don't get 
taught in schools. First and most importantly, choosing the best 
algorithm for a part of the program that has no participation to the 
performance profile has a negative effect on optimization because it 
wastes your time that could be better invested in making actual 
progress, and diverts attention from the parts that matter."

I don't think its true that it "doesn't get taught in schools", at least 
in CS university degrees. In my degree this was explained in detail at 
least 2 core curricula courses, and a few more times in other non-core 
(optional/specialization) courses. Also, (like I mentioned above) the 
majority of other learning material (articles, books) that talk about 
optimization do mention the importance of profiling.

"Second, algorithms' performance always varies with the statistics of 
the data they operate on. Even bubble sort, the butt of all jokes, is 
still the best on almost-sorted data that has only a few unordered 
items. So worrying about using good algorithms without measuring where 
they matter is a waste of time - your's and computer's."

Also, the notion that an intrinsic part of algorithm design is to 
understand what kind of data you are going to work was also mentioned in 
one of the core curricula courses in my degree (although with less 
detail than with case 1, above).

I don't mean to offend anyone, but if you CS degree (at least for the 
last decade or so), doesn't teach about points 1 and 2 above as part of 
core curricula, then it's a pretty crappy CS degree. The same is 
probably also true for other related degrees (*-engineering, maths), at 
least with regards to point 1.

-- 
Bruno Medeiros - Software Engineer