I obsess over code performance, probably a little bit too much. But there’s a big reason for wanting a code to run in less than an hour instead of slightly more than two hours. The reason is because a code’s speed interacts with how we go about our day, and this speed can have a nonlinear effect on our productivity.

Here’s a concrete example. When I was a PhD student, I had a project which was solving ensembles of stochastic partial differential equations which were a model of the zebrafish hindbrain. Each run of this ensemble took about two hours and ten minutes to perform. For a good chunk of time, I needed to keep running these ensembles in order to manually check the output to tweak the model until it started to look realistic. Tweaking the model took only a few minutes, so I figured I’d be done with this in no time because I could run the code 10 times a day!

Well… that’s without the realities of life getting in the way. At that time I was taking courses, and so if I started the run just before class started, two hours and ten minutes was more than the time of two courses, so the quickest I’d be able to tweak and re-run would be after the third course (3 hours). But 9-12 means I would go and catch lunch with some friends. This means I’d get back at around 1 to start the code. Seminars in the afternoon, girlfriend wants lunch, etc. means the next run happens at night, and then I go to sleep. A code which took just over two hours to run was able to be ran on average 3 times a day when ran “quasi-continuously”. This is the nonlinear effect of run time on productivity.

This is seen at a micro scale as well. Let’s not lie to ourselves. A code which takes 5 minutes to run is the absolute worst. I don’t think most of us just stare blankly at the screen for 5 minutes! This run time is the perfect bait for opening up Hacker News or getting into a conversation on Slack. And after being baited, a code which takes 5 minutes to run ends up being something you’re only checking every 15 minutes. If it’s 15 minutes, you throw on BoJack Horsemen (20 minute episodes, good choice!) and accidentally only check it every two episodes, making it closer to 40 minutes. The actual times just keep growing faster than the run times actually grow!

So getting over a jump can be quite important. Making a code run “instantly” can be key to keeping your attention. Making a code run in a day is something you can plan around. Hitting these markers is what’s key for optimizing your actual productivity. This is why I spend so much time optimizing code, and why I gave Julia a try. While in some cases the performance improvements can look small, the numbers are always incorrect until you add the human factors, and here the human factors are a disaster multiplier which cannot be forgotten.