This is a follow-up to this question (thanks to answers from @fgrieu and @kelalaka ) about the format of a salt when hashing a salted password.
I realize this is pretty much academic, as the proposed uniterated SHA-256 of a salted password is already acknowledged to be much less secure than trusted password storage algorithms (scrypt, Argon2, PBKDF2, etc.). And, this may be a very obvious point, but I haven't found anything mentioning it (quite the opposite).
Nevertheless, considering the use of this (ill-advised, but currently available) approach, when concatenating salt & password, if the salt precedes the password, wouldn't that allow an attacker to optimize away the salt when doing a dictionary or brute force attack, and speed up the results?
Here's my thought: A SHA-256 hash is a left-to-right processing of the source data. While processing the data, the SHA-256 code could be modified to take a snapshot of the intermediate algorithmic values (variables) as the salt is being processed, but just before the first password character is read. This would be done once to collect the values. Then a further modification of the SHA-256 code, which allowed the hash for each try to begin with the intermediate values previously stored. This would allow only the characters of the test passwords to be processed on each try, eliminating the overhead of processing the (presumably 256-bit) salt, but still providing the correct SHA-256 result.
Again, assuming no iterations, and no nested hashing, wouldn't it be better for the password to precede the salt, so that the attacker had to process the salt data to obtain the correct SHA-256 value for every try?