-
Bug
-
Resolution: Fixed
-
Minor
A user working with files in the 100+ Mb range asked whether fingerprinting them was expensive. Probably it is not that expensive but it is likely the implementation could be optimized and at least measured.
As far as the I/O goes, FilePath.digest uses FileInputStream rather than NIO—hmm, maybe OK. It does not use buffering, which may or may not be an issue here. Then it calls Util.getDigestOf.
That uses the JRE’s MD5 implementation which AFAIK takes advantage of any cryptographic hardware acceleration when available. It does read into a 1024-byte buffer however which seems excessively small. (And uses a proxy stream rather than simply calling the update method, which is odd.) http://stackoverflow.com/questions/9321912/very-slow-when-generaing-md5-using-java-with-large-file suggests using a custom library though this may be overkill; others suggest DigestUtils from Commons Codec. A
- depends on
-
JENKINS-18178 All Maven 2 builds fail with java.lang.NoSuchMethodError DigestUtils.md5Hex
- Resolved
-
JENKINS-19515 fingerprint are truncated
- Resolved
-
JENKINS-18337 Fingerprint throws exceptions on 1.518
- Resolved
- is related to
-
JENKINS-13154 Heavy thread congestion with FingerPrint.save
- Resolved
-
JENKINS-11814 Maven artifact fingerprints are computed and recorded twice
- Resolved
-
JENKINS-7813 Archiving artifacts very slow
- Resolved
-
JENKINS-17412 Multiple maven builds: Jenkins frequently dies
- Resolved
-
JENKINS-18351 Fingerprinting seems to leak Files
- Resolved