Planning a performance evaluation

A migration decision needs measurements from the path that will change. Published algorithm sizes and laboratory results can inform a test plan, but they cannot establish the latency or throughput of your application.

#Define the workload

• Name the protocol, classical baseline, post-quantum candidate and parameter set.
• Record hardware, software and library versions, network conditions, concurrency and payloads.
• Define which costs are included: key generation, handshake, signing, verification, transfer and storage.
• Set acceptance criteria and record the test environment before comparing results.

#Measure like for like

Run baseline and candidate under comparable conditions. Report repeated measurements, variability, failures and the latency percentiles relevant to the application. A key or signature byte count is not a measured network or application cost.

#Review effort is a separate question

Time spent producing an inventory is different from cryptographic runtime performance. Neither establishes the other. The previously quoted review-speed comparison is not used here as a substantiated benchmark; see Reproducing our numbers for the evidence requirements.

#Keep examples and measurements distinct

Label example values as illustrative. A report used for a production decision should identify the workload, environment, method, raw measurements and limitations. Avoid extrapolating from one service to an entire estate.