in reply to Performance, Abstraction and HOP
What a thoughtful meditation, pg. Thanks to you, and also all the followup posters.
Performance means many things. When you are dealing with outside influences, be they characters coming in on a serial port or user keystrokes, responsiveness is the key measure of performance. In 'hard' real time programming, people can die if your program is not fast enough to handle its inputs.
Most of our programming is not so critical. As has been pointed out, web servers rarely need do much more than yawn to keep up with the bandwidth of their pipes. Likewise, having an entire UNIX machine with gobs of memory and CPU cycles to one's own self does tend to make one complacent when it comes to CPU-oriented performance tuning. As has already been said, we really do need to make our programs polite enough not to hog the machine where community usage is the case.
All that aside, I'd like to argue for abstraction for another kind of performance. Many times, I write programs that are used to analyze data produced somewhere else. Often it's the case that the data changes and also the input formatting changes from run to run. Performance and responsiveness, in this case, depend on me as the programmer being able to whack the code into a new shape quickly and correctly.
Likewise, team programming depends on abstraction to protect the members' code chunks from each other. While Java has its faults, team performance (as in productivity) is likely to be better in a Java shop than in a Perl shop.
That's not to say that it isn't often the case that one Perl programmer
can outdo an entire Java shop, but that's another meditation!
Performance means many things. When you are dealing with outside influences, be they characters coming in on a serial port or user keystrokes, responsiveness is the key measure of performance. In 'hard' real time programming, people can die if your program is not fast enough to handle its inputs.
Most of our programming is not so critical. As has been pointed out, web servers rarely need do much more than yawn to keep up with the bandwidth of their pipes. Likewise, having an entire UNIX machine with gobs of memory and CPU cycles to one's own self does tend to make one complacent when it comes to CPU-oriented performance tuning. As has already been said, we really do need to make our programs polite enough not to hog the machine where community usage is the case.
All that aside, I'd like to argue for abstraction for another kind of performance. Many times, I write programs that are used to analyze data produced somewhere else. Often it's the case that the data changes and also the input formatting changes from run to run. Performance and responsiveness, in this case, depend on me as the programmer being able to whack the code into a new shape quickly and correctly.
Likewise, team programming depends on abstraction to protect the members' code chunks from each other. While Java has its faults, team performance (as in productivity) is likely to be better in a Java shop than in a Perl shop.
can outdo an entire Java shop, but that's another meditation!
|
|---|
In Section
Meditations