Do any other factors aside from length of input affect the runtime of the SHA-256 hashing algorithm? To my understanding, the only factor that (even if ever so slightly on most implementations) affects the run time of SHA-256 is the amount of padded chunks the extension &amp; compression function have to run over. The only way to alter the amount of padded chunks is to change the length of the input. Therefore, the only factor influencing the runtime of SHA-256 is the length of payload to be hashed. Is this correct, or are there further aspects that influence the runtime of SHA-256?
Edit: To clarify, this question is talking about the abstract runtime / the runtime on one particular implementation
Your question is not very clear, but I assume you're asking whether the runtime of a SHA-256 invocation depends on anything about the input other than its length. In other words, if an adversary knows how long it takes to calculate SHA-256(M1) and SHA-256(M2), does this leak any information about M1 and M2 other than their length?
The answer, with plausible implementations, is no. SHA-256 (like all common hash algorithms: MD5, SHA-1, SHA2, SHA3, Blake, etc.) only uses the message for bitwise operations (and, or, xor, shifts by a constant size, negation) and additions. All of these operations use a constant time on all common (and most imaginable) hardware, and compilers are very unlikely to turn them into non-constant-time operations. There are no multiplications or divisions (which on many CPU are not constant-time), no shifts by a message-dependent amount, no conditions or table lookups based on a value that's derived from the message content (other than the message's size).
So unlike, say, AES (where the most natural implementation involves a table lookup based on values derived from the key), you generally don't have to worry about timing-related side channels in SHA-256 or other common hash algorithms.
On the other hand, leaks from power consumption can be a worry.