Responses to two recent posts:
Rob Scott's
>
>> I can't count the number of well-coded bubble sorts I have replaced.
>
> My favourite sentence of the day.
>
is a point well taken, but it does need to be contextualized. Bubble sorts are
in fact optimal for key sets that are already very nearly in sequence; and when
a multiset, one containing duplicate keys, is reordered by a bubble sort it
preserves the original ordering of these duplicates, which is sometimes very
important.
Peter Farley wrote:
I beg to differ. In the application-level MIPS reduction project of which I
spoke, just eliminating the use of redundant high-byte-count MVCL's (COBOL
MOVE's, in actual fact) generated about a 10-15% reduction in overall CPU time
consumed by the application during the batch window (we are talking about batch
record volumes into the tens of millions here).
Here we have an old story. A batch window is or shortly will be too small.
What to do? The choice made here was to optimize/reduce record-processing
times. In fact, however, shrinking record-processing times to zero is not
always very helpful in these (MFU) applications. They are I/O-bound. What is
in short supply is residence time not CP cycles, and what one must do is
introduce asynchronous, overlapped I/O. There is no substantive difficulty
here, but the COBOL episteme knows nothing of asynchronous operations, and so
in general they are not considered.
I remain enormously suspicious of low-level performance tinkering. Code that
lasts is elegant, not labored. If you need better performance, get a better
algorithm; and be sure, moreover, that the problem you are treating was chosen
for treatment because it is crucial and not just accessible.
John Gilmore Ashland, MA 01721-1817 USA
