Our performance reports currently are good at informing us about regrressions.

They are not useful to someone trying to gauge whether Daffodil is fast enough to meet their needs.

The simplest initial fix for this is to provide a KBytes/sec statistic. For parsing this is the rate at which input data is consumed. For unparsing it is the rate at which output data is emitted.

(I.e., I/O related to the infoset in the middle isn't relevant).

That additional measure, which is just (files/sec) / (kbytes/file) would be a great improvement to this report.

As a spreadsheet of data, I would prefer to see the things mashed together into test names spread out into columns:

E.g., army-drrs_1t_1.1m_60

as

{{name           nThreads       file size   file size units    nFiles       

army-drrs           1                   1.1            m                 60     }}

For file-size I'd prefer to see it standardized to kbytes actually rather than having this separate units column.

For multi-threaded tests, a statistic to add is speedup factor. This is the Nthread speed (kbytes/sec) divided by the 1 thread kbytes/second, divided by N (number of threads).

Perfect scaling up has speedup factor of 1.
Most things will have speedup factors < 0.5
As you increase the number of threads, the speedup factor should level off and eventually drop.

The above stats would give users who understand the approximate message size of the data they are handling, to get an intuition for "messages/sec" and the speedup curve they should expect from multi-threading.

E.g., for Link16, a typical message is about 32 bytes long.