Doing a checksum on a supplied binary is time consuming. On a typical system, it takes 10-20 ms - which is as long as cwebp uses for converting a typical 80 kb jpeg.
The problem has gotten worse as the supplied binaries has grown - especially for Linux. We now supply 4 different binaries for Linux. The reason behind this is that the binaries have different dependencies, and we want it to work on as many systems as possible. And we also want to supply the newest version. See #196 and #278.
Currently, the checksums are performed on all supplied binaries for the given OS. However, as we know the versions of the cwebps beforehand, it is not neccessary to do a checksum in order to get the version (currently, the version is detected by calling the cwebp with the -version flag). The hash check could be postponed till right before doing the conversion. In case a cwebp binary is found using one of the other methods, and it is not an older version than the supplied binaries, no hash check will need to be run at all.
Doing a checksum on a supplied binary is time consuming. On a typical system, it takes 10-20 ms - which is as long as cwebp uses for converting a typical 80 kb jpeg.
The problem has gotten worse as the supplied binaries has grown - especially for Linux. We now supply 4 different binaries for Linux. The reason behind this is that the binaries have different dependencies, and we want it to work on as many systems as possible. And we also want to supply the newest version. See #196 and #278.
Currently, the checksums are performed on all supplied binaries for the given OS. However, as we know the versions of the cwebps beforehand, it is not neccessary to do a checksum in order to get the version (currently, the version is detected by calling the cwebp with the -version flag). The hash check could be postponed till right before doing the conversion. In case a cwebp binary is found using one of the other methods, and it is not an older version than the supplied binaries, no hash check will need to be run at all.
See #285 for the discussion that lead up to this