bug#60807: [PATCH 1/2] mtime: use Time::HiRes::stat when available for subsecond resolution

On Sun, Jan 15, 2023 at 12:27 AM Mike Frysinger <[email protected]> wrote:
> On 14 Jan 2023 21:27, Jacob Bachmeyer wrote:
> > Mike Frysinger wrote:
> > > --- a/lib/Automake/FileUtils.pm
> > > +++ b/lib/Automake/FileUtils.pm
> > > @@ -42,6 +42,11 @@ use Exporter;
> > >  use File::stat;
> > >  use IO::File;
> > >
> > > +# Perl's builtin stat does not provide sub-second resolution.  Use Time::HiRes
> > > +# if it's available instead.  Hopefully one day perl will update.
> > > +# https://github.com/Perl/perl5/issues/17900
> > > +my $have_time_hires = eval { require Time::HiRes; };
> > > +
> > >  use Automake::Channels;
> > >  use Automake::ChannelDefs;
> > >
> > > @@ -115,10 +120,18 @@ sub mtime ($)
> > >    return 0
> > >      if $file eq '-' || ! -f $file;
> > >
> > > -  my $stat = stat ($file)
> > > -    or fatal "cannot stat $file: $!";
> > > -
> > > -  return $stat->mtime;
> > > +  if ($have_time_hires)
> > > +    {
> > > +      my @stat = Time::HiRes::stat ($file)
> > > +   or fatal "cannot stat $file: $!";
> > > +      return $stat[9];
> > > +    }
> > > +  else
> > > +    {
> > > +      my $stat = stat ($file)
> > > +   or fatal "cannot stat $file: $!";
> > > +      return $stat->mtime;
> > > +    }
> > >  }
> >
> > If you change that variable to a constant, you can eliminate the runtime
> > overhead entirely, since Perl optimizes if(1) and if(0) and folds
> > constants at compile time.
> >
> > Something like:
> >
> >     use constant HAVE_Time_HiRes => eval { require Time::HiRes; };
> >
> > Then:
> >
> >     if (HAVE_Time_HiRes)
> >        ...
> >
> > If you do this, Perl will inline the block actually used and elide the
> > branch at runtime.  This is generally useful for any test that can only
> > go one way in a specific run of the program.
>
> thanks, i'll integrate that idea.  i'm by no means a perl programmer.

Thanks, Mike.
It looks like this has been resolved slightly differently by a recent
change from Paul Eggert, so I'm closing this.