2.2.2 - Performance modelling, pipelines and visualisation

Predict time and resources under stated assumptions

Performance modelling represents how a proposed system uses resources, such as execution time, memory or processing capacity. It supports comparisons and bottleneck investigation before or alongside implementation. A model is a prediction under assumptions, not a measured guarantee.

Suppose a reporting service reads each record in 2 ms, transforms it in 3 ms and saves it in 1 ms. If it completes all three operations for one record before starting the next, the modelled time for $n$ records is $n(2+3+1)$ ms. Four records take 24 ms. Assume fixed stage times, no failures, no startup cost outside these stages and no competing use of the resources.

A memory model can reveal a different trade-off. Holding $n$ records of 100 bytes before processing needs $100n$ bytes just for their payloads. Holding only one record at a time needs 100 payload bytes, but the complete application still needs variables, buffers, program code and representation overhead. A payload estimate is not a total-memory measurement.

Validate the model with representative measurements. If the transform sometimes takes 30 ms instead of 3 ms, a fixed-time prediction misses delays. Include the relevant variation or state its limit. Measurements depend on hardware, data, software and load; an asymptotic complexity describes growth rather than an actual duration in milliseconds.

Feed one process result into the next

A pipeline connects processing stages so that a stage's output becomes the next stage's input. A software pipeline might read records, validate them, transform accepted values and save the result. Each stage needs an interface: the format it accepts, what it emits and how errors are represented.

For a small batch, the following static Python example shows the data feed. None represents a missing reading; negative raw readings are invalid for this instrument. After rejecting these records, the transform subtracts a calibration offset of 10.

readings = [12, None, 18, -3]
accepted = [r for r in readings if r is not None and r >= 0]
adjusted = [r - 10 for r in accepted]
print(adjusted)

accepted is [12,18], then adjusted is [2,8]. The transform consumes the validation stage's result; it does not revisit rejected records. Testing r is not None first avoids comparing None with 0. An empty or entirely rejected batch becomes an empty output list. A negative adjusted value would be valid here if the accepted raw value were below the offset: validate the stated raw-data contract, not an invented restriction on the transformed result.

This code executes stages sequentially and stores complete intermediate lists. A streaming design could pass one accepted record at a time, reducing batch storage and starting later stages earlier. Several records may be in different stages simultaneously if the runtime provides independent stage resources and safe buffers. Merely naming functions “pipeline” does not create overlap or concurrency.

Specify failed-stage behaviour. If saving fails, avoid reporting that the record was stored; a retry policy must also prevent duplicate effects when a save actually succeeded but its acknowledgement was lost. The pipeline interface must carry relevant identity and error information, not just the successful value.

Separate completion latency from pipeline throughput

Latency is the time one item takes from entry to completion. Throughput is the rate of completed items. Overlapping different items can improve throughput without shortening the processing path of the first item.

Return to the 2 ms read, 3 ms transform and 1 ms save stages. Assume each has its own resource, handles one record at a time, processes records in order and starts as soon as its input and resource are available. Buffers can hold waiting records, transfer is immediate and the stage times are fixed. These assumptions permit the following four-record schedule: