As far as performance is concerned, the time to compute an MD5 hash or any other cryptographic hash depends solely on the number of bytes. It doesn't matter what the bytes are.
memset(buffer, ' ', sizeof(buffer)); doesn't create an “empty buffer” — there is no such thing as an empty byte in memory. It fills the buffer with space characters, which are bytes like
'a' or any other.
Security-wise, the time to compute a hash can vary very very slightly depending on the data. This may allow an attacker who doesn't know the data but can accurately measure the time it takes to hash it to obtain some information about the data. For a hash computation, timing attacks are highly unlikely to work in practice, because there is little in the timing that depends on the data. Timing attacks are mostly successful on operations on large integers involved in asymmetric cryptography, and mostly when the attacker can influence the data and the execution speed. For example, if the implementation uses a table that doesn't fit in a single cache line and the attacker can run code on the same processor, the attacker might try to use the cache in his own process, so that the hash computation keeps fetching parts of the table from RAM, allowing the attacker to observe when RAM lookups take place. The implementation can counter that by being cache-oblivious.
In practice, I wouldn't worry about timing attacks on hash computations. Hash comparisons, yes (when comparing two MD5 hashes, one of which is secret, you should compare all 16 bytes and not stop at the first difference). Number of hash computations or comparisons in an algorithm that involves many such, yes. But not for the hash computation itself.