Philip Guo (Phil Guo, Philip J. Guo, Philip Jia Guo, pgbovine)

The practical implications of computer program running times

I divide up computer program running times into the following broad categories:

  • Instantaneous

    • Terminate seemingly instantaneously after launch, often taking less than 1/3 second

    • Can get results immediately—this quick feedback is essential for rapid iteration and refinement of algorithms

    • Extremely amenable for use as sub-routines in larger programs because they can be run hundreds of times within minutes

  • 1 to 30 seconds

    • Still really fast but not instantaneous—there is a noticeable but not overwhelming delay

    • You can still get results immediately so that your attention doesn't get distracted by other activities

    • You can still iterate and refine algorithm many times with rapid feedback

    • However, not as amenable for use as sub-routines in larger programs because they can only be run a few times within minutes

  • Low number of minutes

    • Usually terminate in 1 to 10 minutes

    • You can answer emails, surf the web, or run other errands while waiting but at the risk of losing mental context and concentration

    • A bit annoying because you don't want to wait around for it to finish but can't really do much else useful in the interim

  • High minutes

    • 10 to 45 minutes

    • You can squeeze in a few runs during the course of a work session, but must interleave with other activities

    • Implementation bugs start to get annoying because it's starting to take a long time to run the program

    • In order to refine and tweak parameters, you can automatically run it overnight in up to a dozen different configurations

  • Hours

    • 45 minutes to 4 hours

    • You can only run it a few times per day

    • Fortunately, it's easy to do other work in the interim because there is enough time to complete other tasks while this one is running

  • Overnight

    • 4 to 10 hours

    • You can run once per day—usually run it overnight and analyze the results the next morning

    • Implementation bugs get especially annoying because an entire day's worth of work is wasted if the overnight run fails mid-way through

    • Because it's running overnight, it's often difficult and inconvenient to monitor the run

    • Usually a good idea to debug program by testing on smaller inputs that only take a few minutes

  • Days

    • 1 to 7 days

    • You can only run once per work week

    • Must be extremely careful about implementation details because the consequences of a crash or incorrect behavior are more drastic

    • Must think about building in monitoring and self-repair facilities into the software so that it is less likely to crash mid-way

    • Maybe prefer fail-soft versus fail-fast software design—i.e., prefer getting incomplete results than crashing with no results

    • Almost impossible to iterate rapidly because the turnaround times are so long

  • Weeks

    • 1 to 4 weeks

    • Definitely want to implement fail-soft and constant monitoring and online adjustment facilities in the program

    • Must be able to 'steer' the program's execution while it's running in order to account for unintended conditions

    • Must be able to obtain incomplete and partial results incrementally

  • Forever

    • Anything that takes longer than a month to run

    • The results had better be worth the complexity of the algorithm!

    • Good luck ;)

Created: 2008-07-30
Last modified: 2008-09-21
Related pages tagged as programming: