Downgrading hashing algorithm from SHA3 to SHA1 for caching checksum

[hubertp]

IR caching currently uses SHA3-224 for calculating hashes of individual module sources and their serializations.
The hash is stored in IR metadata and compared during de-serialization.
As noted in documentation this is mostly for consistency since in other places we also seem to stick to SHA3.

Except that in our case we are paying a non-negligible price for using SHA3:

Compare this with timings when I switched to SHA1:

Is there any particular reason why we stick to a more secure version for a simple checksum? Even plain MD5 should be sufficient.

[wdanilo]

I don't think there is a reason for that. Let's use the fastest possible option if other people agree. Btw, if MD5 is even faster, it sound like even better solution.

[hubertp]

@JaroslavTulach @Akirathan @4e6 Would you be OK with the change?

[Akirathan]

Sure, sounds good. The simpler the checksum is for this use-case, the better.

[JaroslavTulach]

Sure. No need to burn CPU on something like that.

[hubertp]

So that change is now implemented. But I noticed another place where we use SHA3 extensively - versioning text buffers, used by both IDE and engine (language server). The change would need to be done in lock step and can be potentially disruptive. On the upside, the quicker we do it the easier it is to deal with it later.