Monday 24 January 2011

Bad code go away now

Some days, I get so wrapped up in Moviestorm as a movie-making tool that I forget it's a piece of software made out of hundreds of thousands of lines of hand-written code. And even once we've got those lines of code to actually do what we want them to do, that's not the same thing as making them do it efficiently. This cartoon from xkcd explains why.



So every often, we go through the code and see if we can figure out what it's actually doing. We find loads of places where it's taking two steps forward and one step back, and try to see if we can make it just take one step forward instead of doing the hokey-cokey all over the place. Here's an email Julian sent me at the end of last week which will give you an insight into what this actually entails.
Well, I've had fun this week. I did some profiling and found that there were some very odd things going on. Why, for example, were there over 160,000 bounding boxes in a particular - fairly simply - scene? Why did the performance problems and crashes only happen when I switched views? And the like...

You will be glad to know that I have answers to both of these and more. A few accidents, going back to last summer, resulted in some innocuous code being checked in. Innocent it looked. But it had the side-effect of adding multiple copies of objects to the scene when it was loaded or changed view. If you stayed in the set workshop though, you'd never see it. And in fact, I found two completely different areas of code where this was happening, leading to a seriously exponential over-allocation, gobbling of RAM, and also CPU cycles. I have removed the first offending item as it was an accident; and I have added extra bullet-proofing to stop the second happening.

Thirdly, those 160,000 boxes came about as a result of some debug code that was used to test our snapping sockets. When you stacked objects, the collision detection system got a bit confused trying to partition things and got stuck in recursive hell. The code was unused anyway, and I have removed it.

Lastly, I have made further modifications - I have speeded up some of the critical loops in the code, and also cut out a bunch of redundant work. The result is that movies load a bit faster, take significantly less memory, and render faster. We think that the performance reduction happened in the summer for release 1.4.1 - we had a few reports of sluggishness. If so, we should be nimbler now than we were then. You should see the results for the next release of the product.

Toodle pip!
If that made no sense, here's a translation for non-programmers. "Unused code made it go slow when you did stuff. Took out kludges & spaghetti and made it better."

Go Jules!

2 comments:

Walvince said...

Excellent news ! So we can hope to see some little improvements with the rapidity of the soft !

Dex said...

Thanks for translating the engineer language.

Now, can someone translate "toodle pip?"