OT: productivity and long computing delays

Discussion in 'Python' started by Paul Rubin, Sep 27, 2006.

  1. Paul Rubin

    Paul Rubin Guest

    I'm doing something where I frequently but unpredictably (i.e. I can't
    plan for it in advance) hit a snag that requires me to rebuild a large
    project. The rebuild takes a couple hours. During that time, I'm
    twiddling my thumbs and/or posting here, i.e. not getting anything
    useful done. But the delay is not long enough that I can really
    switch to another project for a while.

    Anyone got any suggestions? How do you deal with this? It could be
    mitigated with a faster computer (I'm using a 1.2 ghz Pentium M) but
    the overall task isn't large enough to justify going out and buying
    one. Anyway, I did the same build on a 2 ghz Athlon 64 and was
    surprised that the speedup was only 35% or so. I'd have to get a
    multiprocessor box to obtain really substantial gains.
     
    Paul Rubin, Sep 27, 2006
    #1
    1. Advertisements

  2. Paul Rubin

    Larry Bates Guest

    Just guessing - A significant portion of the time might be I/O
    that is disk bound so faster CPU won't help. If that's the case
    faster hard drive (10K or even 15K rpm) or a striped drive array
    could help. You should also check memory, if CPU starts
    swapping, the swap I/O will kill your performance.

    -Larry Bates
     
    Larry Bates, Sep 27, 2006
    #2
    1. Advertisements

  3. Paul Rubin

    skip Guest

    Paul> Anyway, I did the same build on a 2 ghz Athlon 64 and was
    Paul> surprised that the speedup was only 35% or so. I'd have to get a
    Paul> multiprocessor box to obtain really substantial gains.

    Maybe your build process is i/o bound. If you're using GNU make and have
    the make dependencies set up properly, the -jN flag (for N = 2 or 3) may
    speed things up.

    Skip
     
    skip, Sep 27, 2006
    #3
  4. Paul Rubin

    Paul Rubin Guest

    It's almost all CPU-bound on both the Pentium M and the Athlon. But I
    wasn't as much asking for technical approaches to speeding up
    calculation, as for general strategy about dealing with this downtime
    productively (I figured it was ok to ask this, given the other thread
    about RSI). My workday is getting chopped up in a manner sort of like
    memory fragmentation in a program, where you end up with a lot of
    disjoint free regions that are individually too small to use.

    As for the technical part, the underlying problem has to do with the
    build system. I should be able to edit a source file, type "make" and
    recompile just that file and maybe a few related ones. But the
    results of doing that are often incorrect, and to make sure the right
    thing happens I have to rebuild. I'm not in a position right now to
    start a side project to figure out what's wrong with the build system
    and fix it.
     
    Paul Rubin, Sep 27, 2006
    #4
  5. Paul Rubin

    Paddy Guest

    Read documentation,
    Write documentation.
    Play Freecell ;-)

    - Paddy.
     
    Paddy, Sep 27, 2006
    #5
  6. Paul Rubin

    tobiah Guest

    about RSI). My workday is getting chopped up in a manner sort of like
    One way to look at this, is that the work environment is
    always fragmented. Emails, phone calls, co-workers, meals,
    meetings... For many of us, large uninterrupted blocks of coding
    time are rare. In your case, you have blocks of time that
    you feel are too small to be used toward another project. I know
    the feeling well. I'll sit for two minutes staring at the screen
    waiting for a download, or a compile, when I know darned well I
    could use that time for something else.

    How about a task 'stack'. Make a (electronic) list of all projects
    according to priority, with space for a 'register snapshot' next to
    each entry. When a delay shows up in the current project, write a
    note describing what you were doing when the task was interrupted,
    and go to the highest priority task available in the list. Read the
    note next to the task name, and you are off on the next task, if only
    for a half hour, or in your case one or two hours. When the higher
    priority task is available again, update the current task context note
    to reflect the state after your work, and jump to the old task, checking
    it's context to refresh your state of mind.

    Tobiah
     
    tobiah, Sep 27, 2006
    #6
  7. Paul Rubin

    beliavsky Guest

    Two hours is a long time! Maybe it takes a programmer 10 minutes to get
    his mind focused on a new project, but that still leaves 110 productive
    minutes. I think many programmers in corporate environments would
    regard 2-hour blocks as luxuries. I have wondered the same thing as you
    (how to be productive during "gaps"), but in situations where I am
    often waiting a minute for a program to compile or run, not hours. I
    suggest immersing yourself in the second project during 2-hour gaps.
    programmer than I. I am a "quant" who programs, not a "programmer". But
    those are my thoughts.
     
    beliavsky, Sep 28, 2006
    #7
  8. Paul Rubin

    Paul Rubin Guest

    Yeah, I don't multitask very well, unfortunately. I think this
    specific situation is a little bit more frustrating than usual,
    because I don't really have a second project of nearly such priority,
    but I can't just go to the beach or something while these builds are
    running. Also, I'm not exactly trying to develop code for this task
    (i.e. implement a new subsystem involving writing a lot). Rather, I'm
    trying to make some small changes to a complex existing program, which
    means I make a few small edits, then end up having to rebuild, and
    take this huge delay before I can find the next bug, and by then I've
    lost all my context. I'm in somewhat of a hurry to finish this, but
    I'm slowed down a lot by all these rebuilds. The 2 hour builds are
    actually a big improvement since I chopped out some subsystems that
    were taking a lot longer. There's another issue too, which is that
    the codebase keeps changing as other people check stuff in, so by the
    time I've gotten done testing my stuff, I have to sync up and test
    some more, etc.

    I suppose I'm mostly just blowing off steam by posting about this. I
    do think I might buy a Turion X2 1.6 ghz machine soon, which should be
    about 2.5x faster than what I'm using right now.

    Anyway, my build just finished so I better get back to it ;-). But I
    think the overall task is about done, unless there's another bug.
     
    Paul Rubin, Sep 28, 2006
    #8
  9. Paul Rubin

    Steve Holden Guest

    Well why not study it while the build system is running? Needn't be a
    full-blown project, but it sounds like you might save yourself a lot of
    pain for relatively little effort.

    regards
    Steve
     
    Steve Holden, Sep 28, 2006
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.