The graph I looked at (that I was supposed to link in parentheses, but apparently failed) comes from [0] and actually shows crypt() performance as a function of key length, comparing different hashing alorigthms. Admittedly, not purely a sha256 benchmark, but possibly even more relevant to passwords. It looks pretty linear to me, so extrapolating to 50kB gives me 0.3625 seconds.
That being said, I just ran a very simple test with just sha256sum and broke 0.3s only at 32MiB, so either crypt() is doing much more than I tought (is salting _that_ expensive?) or I am reading that post completely wrong.
It should give you much more than that, considering that the green (SHA256) graph hits almost 0.1s at just 1000 bytes of input.
>either crypt() is doing much more than I tought (is salting _that_ expensive?)
glibc crypt() is probably doing more than you thought, but it's not salting: in SHA256 mode, various combinations of the key and intermediate hash digests are repeatedly hashed in a certain pattern for 5000 times, although the number of rounds can be changed just like the hashing algorithm. (This is a glibc implementation detail; not all crypt() implementations support extensions like SHA256 mode.)
In general, all general purpose cryptographic hash functions are reasonably fast.
That being said, I just ran a very simple test with just sha256sum and broke 0.3s only at 32MiB, so either crypt() is doing much more than I tought (is salting _that_ expensive?) or I am reading that post completely wrong.
[0] https://stackoverflow.com/a/32909765