Bug#877418: dh-strip-nondeterminism: kills clojure performance

[Chris Lamb]

tags 877418 + confirmed
thanks

Hi Rob,

> I noticed that Debian's clojure-1.8.0.jar had terrible performance as
> compared to both the upstream jar

Oh boy, this sounds fun!

I can confirm it is due to strip-nondeterminism. In particular, the
part that sets the last modified date of the .jar contents (!):

  --- a/lib/File/StripNondeterminism/handlers/zip.pm
  +++ b/lib/File/StripNondeterminism/handlers/zip.pm
  @@ -198,8 +198,6 @@ sub normalize {
   		$zip->addMember($member);
   		$options{member_normalizer}->($member)
   		  if exists $options{member_normalizer};
  -		$member->setLastModFileDateTimeFromUnix(
  -			$File::StripNondeterminism::canonical_time // SAFE_EPOCH);
   		if ($member->fileAttributeFormat() == FA_UNIX) {
   			$member->unixFileAttributes(
   				($member->unixFileAttributes() & oct(100))

Applying this hunk removes the observed performance regression entirely,
despite it altering the .jar (different sha1sum, etc.).

What might be a useful/relevant detail here is that if I apply the following
diff, *clamping* the time rather than always setting it:

  --- a/lib/File/StripNondeterminism/handlers/zip.pm
  +++ b/lib/File/StripNondeterminism/handlers/zip.pm
  @@ -198,8 +198,9 @@ sub normalize {
   		$zip->addMember($member);
   		$options{member_normalizer}->($member)
   		  if exists $options{member_normalizer};
  -		$member->setLastModFileDateTimeFromUnix(
  -			$File::StripNondeterminism::canonical_time // SAFE_EPOCH);
  +		my $canonical_time = $File::StripNondeterminism::canonical_time // SAFE_EPOCH;
  +		$member->setLastModFileDateTimeFromUnix($canonical_time)
  +		  if $member->lastModTime() > $canonical_time;
   		if ($member->fileAttributeFormat() == FA_UNIX) {
   			$member->unixFileAttributes(
   				($member->unixFileAttributes() & oct(100))

… I get about a 25% performance regression:

 1.23s user 0.06s system 191% cpu 0.673 total
 2.08s user 0.09s system 231% cpu 0.940 total

Also, setting $canonical_time far in the future results in zero
performance regression again.

This makes no sense whatsoever unless, perhaps, Java is ignoring .class
files at runtime based on their modification date compared to the current
time...?


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org / chris-lamb.co.uk
       `-