This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Good programmers don't write slow code?
Feed Title: David Buck - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/buck-rss.xml
Feed Description: Smalltalk can do that
I've heard it said that "good programmers don't write slow code". Well, I hate to say it, but this is outright wrong. There is normally a tradeoff between code simplicity and speed. My strategy is normally to make the code simple first so I can get it running. Once it runs, use the performance profiler to determine what's slow and optimize that part hopefully with better algorithms.
I was working on one project in Smalltalk/V for an insurance company. They were calculating illustrations of insurance policies over 20 years or more. We used a model similar to a spreadsheet except that each column had a formula instead of each cell.
At one point, the customer said that they wanted to solve for a value in the last row by changing another value in the first row. We used the bisection method to narrow down the answer because it was the easiest algorithm to implement and get the answer.
This technique worked well for a while but when they tried it on a more complex policy, it started taking over several minutes to calculate. They started to panic and assigned someone to look into rewriting the code in C to get performance.
I told them that re-writing it in C might give them a performance improvement of 5 times or so (for heavy floating point calculations). Let's see what we can do with Smalltalk first. We could use a better algorithm than bisection to find the zero of functions. Rikker's method would give us about 5 times improvement. Then we could calculate only the columns that contribute to the answer while we are solving. That gives an additional 3 times. Then there were some columns that only had an effect for a range of rows and would calculate to 0 otherwise. Eliminating these calculations would give us another 2 times improvement. The total improvement was 30 times which would far exceed the benefit of re-writing it in C.
Using slow algorithms is often the easiest way to get things running. Once it runs, determine if it's too slow then improve performance as needed. If you can, make high level optimizations rather than low level ones - if you can run something slow less often, it's usually better than making the slow thing faster.
Previous Topic
