A hash function like MD5 processes a message of arbitrary length (up to some ludicrously large maximum length, some zillions of terabytes). The raw computational cost of MD5 can be roughly split into three parts:
- Initialization: set some internal state values.
- Data processing: mostly proportional to the input length.
- Finalization: the "closing computations" of the hash function, yielding the final output (things like padding occur at that step).
OpenSSL, in its benchmarks, measures the speed of doing the three steps with messages of various lengths, so that you might somehow infer the cost of the data processing and the cost of the two other steps.
However, such benchmarks are meaningless because they measure the code performance under unrealistic conditions. When OpenSSL runs, it goes into a tight loop, hashing millions of messages in a row: this ensures that the hash function code itself is in L1 cache, that branch prediction in the CPU is fully aware of the probable direction of each conditional jump, and that the input data is also in the CPU L1 cache. None of this really applies to a practical situation.
In practice, I/O and RAM bandwidth costs will dominate, especially with "fast" hash functions like MD5; also, the hash function is not alone in the data path, and other tasks will matter. For instance, in your code, the call to
strlen() will not have a negligible impact when compared with MD5 (it will be faster, but not to the point of not even showing up in measures).
What you should do is to measure performance of your complete system, not the hash function alone; and do that with a few select hash functions: this will use the actual execution context. Also, it is improbable that the hashing cost itself represents a substantial proportion of your CPU.