OT: productivity and long computing delays

P

Paul Rubin

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.
 
L

Larry Bates

Paul said:
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.

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
 
S

skip

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
 
P

Paul Rubin

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.

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.
 
P

Paddy

Paul said:
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.

Read documentation,
Write documentation.
Play Freecell ;-)

- Paddy.
 
T

tobiah

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.

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
 
B

beliavsky

Paul said:
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.

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.
From reading your posts here I think you are a more experienced
programmer than I. I am a "quant" who programs, not a "programmer". But
those are my thoughts.
 
P

Paul Rubin

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.

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.
 
S

Steve Holden

Paul said:
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.

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top