Performance: measuring and writing efficient COBOL

Adding 1.25 to a total 10 million times took 0.836 seconds of CPU with the two fields in USAGE DISPLAY and 0.300 with COMP-5, on the same laptop, for the same total. Numbers like these decide where a change pays for itself, but only if they are measured the same way every time and reported with the machine, the compiler and the data they came from.

This lesson sets up that measurement and applies it to COBOL’s usual costs: the USAGE of numbers in arithmetic, the way a table is searched, and how often a file is opened. Every timing here was recorded with GnuCOBOL 3.2 on one busy machine, which the lesson names, and none of them is a statement about z/OS.

Measure the same way every time, and say how you measured

A timing is evidence only with its conditions. The run report of every measurement on this page names the machine, an Apple M5 Pro with macOS 26.7.1, the compiler, GnuCOBOL 3.2 with cobc -O2, which passes optimisation to the C compiler, the data and the number of runs. It reports CPU timeCPU time: The seconds a processor spent running a program's own instructions, user time for its code and system time for the requests it made to the operating system, such as OPEN and CLOSE. Waiting for a processor or a disk is not counted., the seconds the program itself kept a processor busy, user and system, and not wall-clock timewall-clock time: The elapsed time of a run from start to end, as a clock on the wall would show it, including every wait for a processor, a disk or another job. On a busy machine it changes far more from run to run than CPU time.: this machine shared its cores with other work, which stretches elapsed time far more than CPU time.

bench.sh runs each variant once to show its output, then three rounds in which every variant runs once in turn, so a busy moment falls on all of them alike, and prints each run’s CPU seconds with the median:

#!/bin/bash
# Usage: ./bench.sh ROUNDS PROGRAM...: runs each program once to show what it
# prints, then ROUNDS rounds in which every program runs once, in turn, so that a
# busy moment of the machine falls on all of them alike. It prints the CPU
# seconds, user plus system, of every timed run and the median of each program.
set -eu
rounds=$1
shift
for p in "$@"; do
  echo "$p: $(./"$p")"
done
TIMEFORMAT='%U %S'
for r in $(seq "$rounds"); do
  for p in "$@"; do
    { time "./$p" > /dev/null; } 2>&1 | awk '{ printf "%.3f\n", $1 + $2 }' >> "cpu-$p.txt"
  done
done
for p in "$@"; do
  runs=$(tr '\n' ' ' < "cpu-$p.txt")
  median=$(sort -n "cpu-$p.txt" | sed -n "$(( (rounds + 1) / 2 ))p")
  echo "$p: CPU seconds ${runs}median $median"
done

The routine around it matters as much as the script. The golden-file tests of the tooling lesson pass before the first measurement and after every change, one change is measured at a time, and a gain smaller than the spread between rounds is not a gain:

The same routine serves every change in this lesson, from the cheapest to try to the ones only a run on z/OS can judge:

A lookup inside a read loop and a file opened for every record both repeat once for every record of the input, so their cost grows with the file. The three options change no line of the source, which is why only a timing on z/OS can judge them.

USAGE decides what arithmetic costs, measured on 10 million additions

ADDLOOP adds an amount of PIC S9(3)V99 to a total of PIC S9(15)V99 10,000,000 times. Four builds differ only in the USAGEUSAGE clause: The clause that says how an item's value is stored: DISPLAY as characters, PACKED-DECIMAL or COMP-3 as packed digits, BINARY, COMP or COMP-5 as binary integers, and COMP-1 or COMP-2 as floating point. More in “USAGE: zoned, packed decimal (COMP-3) and binary” of those two fields, which sed writes in:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. ADDLOOP.
      * Adds 1.25 to a total 10,000,000 times. The USAGE of AMOUNT
      * and TOTAL is the only difference between the four variants:
      * the session writes it in place of USAGE-HERE with sed.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  AMOUNT       PIC S9(3)V99  USAGE USAGE-HERE VALUE 1.25.
       01  TOTAL        PIC S9(15)V99 USAGE USAGE-HERE VALUE 0.
       01  N            PIC 9(8) COMP-5.
       01  SHOWN        PIC Z(14)9.99.
       PROCEDURE DIVISION.
           PERFORM VARYING N FROM 1 BY 1 UNTIL N > 10000000
               ADD AMOUNT TO TOTAL
           END-PERFORM
           MOVE TOTAL TO SHOWN
           DISPLAY "total " FUNCTION TRIM(SHOWN)
           STOP RUN.

from session import files, run

# The machine and the toolchain, then ADDLOOP built in four USAGE variants with cobc -O2 and timed in three rounds.
# The timings change from run to run; the page reports the recorded ones.
files("addloop.cob", "bench.sh")
run("""
uname -m && sysctl -n machdep.cpu.brand_string && sw_vers -productVersion
cobc --version | head -n 1 && cc --version | head -n 1
for u in DISPLAY COMP-3 COMP COMP-5; do sed "s/USAGE-HERE/$u/" addloop.cob > "add-$u.cob" && cobc -x -O2 -o "add-$u" "add-$u.cob" || exit 1; done
./bench.sh 3 add-DISPLAY add-COMP-3 add-COMP add-COMP-5
""")

$ uname -m && sysctl -n machdep.cpu.brand_string && sw_vers -productVersion
arm64
Apple M5 Pro
26.7.1
$ cobc --version | head -n 1 && cc --version | head -n 1
cobc (GnuCOBOL) 3.2.0
Apple clang version 21.0.0 (clang-2100.3.34.2)
$ for u in DISPLAY COMP-3 COMP COMP-5; do sed "s/USAGE-HERE/$u/" addloop.cob > "add-$u.cob" && cobc -x -O2 -o "add-$u" "add-$u.cob" || exit 1; done
$ ./bench.sh 3 add-DISPLAY add-COMP-3 add-COMP add-COMP-5
add-DISPLAY: total 12500000.00
add-COMP-3: total 12500000.00
add-COMP: total 12500000.00
add-COMP-5: total 12500000.00
add-DISPLAY: CPU seconds 0.836 0.837 0.829 median 0.836
add-COMP-3: CPU seconds 0.366 0.369 0.363 median 0.366
add-COMP: CPU seconds 0.321 0.333 0.331 median 0.331
add-COMP-5: CPU seconds 0.300 0.304 0.288 median 0.300

All four printed the same total, 12,500,000.00, and the medians were far apart:

The spread inside each row, 0.016 seconds or less, is small next to the gaps between rows, so the order is real. A DISPLAY item holds one digit a byte, as characters, so each ADD works on characters before it can add. COMP-5 is a binary number in the machine’s own byte order. COMP is binary too, but GnuCOBOL keeps it big-endian, as the USAGE lesson showed, and this laptop’s processor is little-endian, which is the likely reason for its small extra cost.

Practise: measuring and USAGE

The questions cover the two sections above, and each wrong choice names the slip it comes from.

Four lookups timed, from a DISPLAY subscript to SEARCH ALL Pro: opens with a Pro, Premium or Ultimate pass

Files: one OPEN for all lines, measured, and the output checked unchanged Pro: opens with a Pro, Premium or Ultimate pass

On z/OS: OPTIMIZE, ARCH, NUMPROC and the data types IBM recommends Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

The first question is a warm-up with its full answer. The other three each begin with a batch job that has slowed down:

Key takeaways

• A timing counts as evidence only with its machine, compiler, flags, data and runs: CPU seconds of interleaved rounds, compared by their medians, with the golden tests passing before and after.
• On this machine 10 million additions cost 0.836 CPU seconds in DISPLAY and 0.300 in COMP-5, so fields in heavy arithmetic belong in a computational USAGE.
• These are GnuCOBOL numbers on one laptop; z/OS decisions are measured on z/OS.