Bug#834797: lintian: depends on libdata-alias-perl, broken with Perl 5.24
On Sun, Aug 21, 2016 at 10:56:20PM +0300, Niko Tyni wrote:
> On Fri, Aug 19, 2016 at 01:37:36PM +0200, Jakub Wilk wrote:
> >
> > * Niko Tyni <ntyni@debian.org>, 2016-08-19, 09:42:
> > > This package depends and/or build-depends on libdata-alias-perl, which
> > > breaks with Perl 5.24 (currently in experimental.)
> >
> > This dependency was added in 516add8dc237 "to avoid copying large texts in
> > memory". But my understanding is that Perl >= 5.20 has copy-on-write
> > strings[0], so this optimization is no longer necessary. Jessie has a
> > sufficiently new version, so the use of Data::Alias can be safely dropped.
> >
> > [0] http://perldoc.perl.org/perl5200delta.html#Performance-Enhancements
>
> Thanks for looking at this! That makes sense to me fwiw, but I see in
> #795641 that the patch author was using 5.20 at least when sending the
> patch. So presumably there was a reason for this?
FWIW, I tested lintian 2.5.46 / Perl 5.22 execution speed a bit with
this (simulating the 'copyright-file-lacks-pointer-to-perl-license' check):
% perl -MBenchmark -MFile::Slurp -e 'require q(./checks/copyright-file.pm); $cr=read_file(shift()); timethis(1000, sub { $_=$cr; Lintian::copyright_file::check_names_texts(qr/\b(?:perl|artistic)\b/, sub { /(?:under )?(?:the )?(?:same )?(?:terms )?as Perl itself\b/i && !m,usr/share/common-licenses/,; })})' ~/tmp/perl/debian/copyright
With an unmodified check_names_texts():
timethis 1000: 12 wallclock secs (12.19 usr + 0.03 sys = 12.22 CPU) @ 81.83/s (n=1000)
With 'alias' removed:
timethis 1000: 12 wallclock secs (12.36 usr + 0.02 sys = 12.38 CPU) @ 80.78/s (n=1000)
With '\$_ = $_[0];' instead (and enabling the 'refaliasing' feature):
timethis 1000: 12 wallclock secs (12.05 usr + 0.01 sys = 12.06 CPU) @ 82.92/s (n=1000)
The file tested (src:perl copyright file) is ~100Kbytes, which I expect
to be larger than average (though I'm sure there are larger ones in
the archive.)
Obviously this doesn't test memory usage, but at least these differences
don't seem worth optimizing for (unless I goofed up somehow.)
--
Niko Tyni ntyni@debian.org
Reply to: