The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Optimising Code for Speed

I recently published a new essay about optimising code for speed:

http://www.shlomifish.org/philosophy/computers/optimizing-code-for-speed/

See also a coverage on OSNews:

http://osnews.com/story/20973/Optimizing_Code_for_Speed

I mention Joel's "Schlemiel the Painter" syndrome there as a way to reduce the order of complexity (or not increase it in the first place).

Comments are welcome.
Shlomi Fish Send private email
Saturday, February 14, 2009
 
 
I don't know what I was expecting from this, but it was certainly more.

I think you could have compressed a few of the opening paragraphs. Like the "Which types of programs require optimization". In my experience, it's any program that's too slow. You try and list several types where it is likely and then end with "programs that are too slow or perceived to be too slow", which is pretty much any type of software.

Some of the opening stuff sounds a bit wishy washy to me. You should not optimize if it runs fast enough, but, well, it may not if somebody is using old hardware, so you should. Sounds like I'm damned if I do and damned if I don't. In fact, I think you could have eliminated the when not to optimize paragraph entirely and the article wouldn't have lost anything.

Most of the examples feel very hit and run to me. I think every one of them could be very interesting, but could have used much more explanation. The essay feels more like a summary of a book. In particular, I think the case study for the Freecell solver would have benefitted greatly from examples.

Personally I also believe the section on Optimizing by Compromising on Security is a red herring at best. Having had to profile and optimize many different applications in several languages over the past 15 years I never once had to remove checks for validating input or graceful error handling. I would venture to say anybody suggesting this had better have some irrefutable data to back up the claim and have exhausted all other possibilities.

Overall I find the topic of optimizing software very interesting. In my opinion too few developers care at all about the performance of their code and many don't have the first clue of how to make things better when they discover a problem.

Also, I'm surprised there is no mention at all of Duff's device. http://www.lysator.liu.se/c/duffs-device.html

While a catalog of optimizations might be useful, I think that it would be tough to come by as many optimizations are dependent on language and environment. Loop unrolling in general can be done anywhere, but you can't do something like Duff's device in C. One of the simplest optimizations I've ever done that resulted in a tremendous increase in performance was to change a parameter on a function in a VB program from 'Object' to the specific thing being represented. String manipulations are also a place that is ripe for optimization in most programs. Again, these are very dependent on the types of objects and structures available. And then there are database and query optimizations which vary greatly between implementations.

Lastly, I think the essay could have benefited greatly in having more links to external resources. As you mention, you barely scratch the surface. Many of the links I saw are to wikipedia entries, which don't do much for me. If I find this article interesting I'm going to want to more digging on optimization, not get definitions for things that I can just as easily look up myself.

I guess for me this was exactly the wrong length. Either a higher level essay or taking one or two specific points and breaking them down with good examples would have been more interesting to me. You cover a breadth of material here that could go into an entire book, and go into enough depth on a couple of points to be frustrating because there is obviously more information that can be provided, but it isn't there and you don't offer more resources to go visit, either.
Bart Park Send private email
Sunday, February 15, 2009
 
 
I agree with everything from Bart Park.

I believe that your discussion of profiling is disproportionately short. Profiling is the bedrock of optimisation.

A discussion of the different types of profilers and their benefits/drawbacks. How to profile manually (when profiling tools are not available).

 The other problem is that more guidance should have been given in the area of when to optimise. Programmers should avoid premature optimisation. Programmers should avoid introducing bugs when optimising.

-Andrew
teambob Send private email
Sunday, February 15, 2009
 
 
I would like to add that knowledge of implementations is a must for good optimization. I more or less agree with "do not do premature optimization." Depends on how doing so will affect the code.

In Python, adding to and removing from the end of a list type is said to be very fast, but adding to the beginning of a list is expensive (arrays implementation?).

If you are about to write a STACK class and you start with the idea that you will be working from the end of your internal list, you will be writing your methods accordingly. Now, there are other implementations of lists data structure in which adding to and removing from the start might not be expensive.

So sometimes premature optimization can tailor up your entire class. Ok, that's just my opinion.
Victor the Python Artist Send private email
Sunday, February 15, 2009
 
 
>"do not do premature optimization."

The advice is good but the devil is in the word premature. Which optimizations are "premature" and which aren't?

Some optimizations should definitely be done early, eg. an experienced programmer is going to choose most-likely containers and algorithms from the very start.

In the case of C++ he/she should also be using lots of typedefs and creating iterator types to traversing the data structures in the anticipation that things will probably change as the project progresses.

This "pre-optimization" can save a lot of refactoring later on.
Jimmy Jones Send private email
Monday, February 16, 2009
 
 
Our (simplified) approach  (for desktop software):

1: Design
 - Choose appropriate algorithms

2: Develop
 - Optimize for readability and simplicity

3: Test
 - Real-life use on 3-5 years old hardware (to identify bottlenecks)
 - Extreme cases ("max out")

4: Optimize bottlenecks
 - Focus mainly on large loops (if it is not in a loop, it's usually not worth sacrificing readability for speed)

In our case, testing on a Pentium III was very useful. Also, try to test extreme use (testing iKnow with 150.000 notes revealed some bottlenecks)
Atle Iversen (iKnow) Send private email
Monday, February 16, 2009
 
 
For desktop apps: Load a massive data file and try to work with it - cut, copy, paste, move stuff around. eg. Text editor - lines with 60,000 chars in them. 3D - A couple of million polygons. etc.
Jimmy Jones Send private email
Monday, February 16, 2009
 
 
PS: The "big file test" is what really separates the C++ from the Java IMHO.
Jimmy Jones Send private email
Monday, February 16, 2009
 
 
Optimizing what the profiler says are critical points is what I see most often advertised as being optimization.  However, one must keep in mind that optimization may have different goals, depending on requirements. Minimizing disk usage might be quite a valid optimization requirement, under certain circumstances. It's not always usage of processor cycles and mem bytes that you have to minimize.

Also, in my experience, after you use a specific language/technology/library/platform for a longer time, you gain some experience about what is expensive and what not. I see no point in not using  idioms/code patterns which you know are cheap (in terms of processor cycles and mem consumption), or designing compact, easy to access/iterate data structures, when you write the code for the very first time. Using less processor and memory can't harm, IMO.
Florin Jurcovici Send private email
Monday, February 16, 2009
 
 
You can also make large order of magnitude performance gains in your overall design through:

* Caching
doing it once is faster than doing it 100 times
* Queuing
it doesn't hasten an individual operation but it does wonders for the worst case scenario
* Initialisation on demand
if you don't need to do it, don't
* Choice of database management system
I've seen a two order of magnitude improvement here
* Scaling
will it scale to more or bigger hardware?

I'm sure we can think of much more.
John Ridout Send private email
Tuesday, February 17, 2009
 
 
There's nothing in there about optimizing queries.
Stuff like when to use an index, or how to use a where clause to get just the rows that you need rather than the whole table (I've seen this more than once). Updating multiple values in one go, rather than writing a curser to loop over the values.
Knowing when something's I/O bound (this can happen with C/S apps) and how to make you application less "chatty".
Mike Swaim Send private email
Tuesday, February 17, 2009
 
 
We optimize everything. So what do we optimize the most? We optimize for sales.
jz Send private email
Thursday, February 19, 2009
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz