Skip Menu |
 

This queue is for tickets about the strictures CPAN distribution.

Report information
The Basics
Id: 87923
Status: resolved
Priority: 0/
Queue: strictures

People
Owner: Nobody in particular
Requestors: perl [...] toby.ink
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: 1.005000

Attachments


Subject: strictures.pm unnecessarily loads constant.pm, utf8_heavy.pl, etc.
Download (untitled) / with headers
text/plain 990b
strictures defines a constant using constant.pm. The versions of constant.pm bundled with Perl prior to 5.18 are a little heavier than would be nice. (This has been addressed in the 5.18.x releases of Perl, and in the CPAN releases of constant.) However, for people with older versions of constant.pm, it would be nice if strictures avoided loading it. A patch is attached to solve this. On my netbook, using Perl 5.16.2, before the patch, I get times like the following: $ time perl -Istrictures-1.004004/lib -Mstrictures -e1 0.104u 0.004s 0:00.11 90.9% 0+0k 0+0io 0pf+0w $ time perl -Istrictures-1.004004/lib -Mstrictures -e1 0.100u 0.008s 0:00.12 83.3% 0+0k 0+0io 0pf+0w And after applying the patch, I get the following: $ time perl -Istrictures-dev/lib -Mstrictures -e1 0.020u 0.008s 0:00.03 66.6% 0+0k 0+0io 0pf+0w $ time perl -Istrictures-dev/lib -Mstrictures -e1 0.012u 0.016s 0:00.02 100.0% 0+0k 0+0io 0pf+0w So it does make a small, but measurable difference to load times.
Subject: strictures-no-constantpm.patch
diff -urN strictures-1.004004/lib/strictures.pm strictures-dev/lib/strictures.pm --- strictures-1.004004/lib/strictures.pm 2012-11-12 19:04:07.000000000 +0000 +++ strictures-dev/lib/strictures.pm 2013-08-18 20:25:28.127643048 +0100 @@ -3,7 +3,7 @@ use strict; use warnings FATAL => 'all'; -use constant _PERL_LT_5_8_4 => ($] < 5.008004) ? 1 : 0; +BEGIN { *_PERL_LT_5_8_4 = ($] < 5.008004) ? sub(){1} : sub(){0} }; our $VERSION = '1.004004'; # 1.4.4
Subject: Re: [rt.cpan.org #87923] strictures.pm unnecessarily loads constant.pm, utf8_heavy.pl, etc.
Date: Sun, 18 Aug 2013 15:02:19 -0700
To: Toby Inkster via RT <bug-strictures [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
Download (untitled) / with headers
text/plain 372b
On Sun, Aug 18, 2013 at 03:38:40PM -0400, Toby Inkster via RT wrote: Show quoted text
> A patch is attached to solve this. On my netbook, using Perl 5.16.2, before the patch, I get times like the following:
Instead of hacking the symbol table, we could also just make a local lexical: my $long_name_I_cannot_remember; BEGIN { $long_name_I_cannot_remember = ( constant expression here ) }
Download (untitled) / with headers
text/plain 507b
On Sun Aug 18 18:02:33 2013, ETHER wrote: Show quoted text
> On Sun, Aug 18, 2013 at 03:38:40PM -0400, Toby Inkster via RT wrote:
> > A patch is attached to solve this. On my netbook, using Perl 5.16.2, > > before the patch, I get times like the following:
> > Instead of hacking the symbol table, we could also just make a local > lexical: > my $long_name_I_cannot_remember; BEGIN { $long_name_I_cannot_remember > = ( constant expression here ) }
That would have a run-time overhead. Using an inlinable sub avoids that.
Download (untitled) / with headers
text/plain 310b
As sprout says, a lexical doesn't allow compile-time optimization like a constant does. And I wouldn't really characterize it as "hacking" the symbol table. It's merely "making use of, in a well-documented and completely supported manner" the symbol table. It doesn't even need strict refs to be switched off.
Download (untitled) / with headers
text/plain 257b
It is of course possible to make a lexical, and have it available from a () prototyped sub. I doubt that would actually look any nicer than just assigning to a glob though. For something lower level like this module is, I wouldn't mind seeing this change.
This will be fixed in the next release.
Fixed in 1.005000


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.