Front page | perl.perl5.porters |
Postings from June 2011
[perl #93324] [PATCH] Remove B from Carp
Thread Next
From:
Father Chrysostomos via RT
Date:
June 26, 2011 12:35
Subject:
[perl #93324] [PATCH] Remove B from Carp
Message ID:
rt-3.6.HEAD-16080-1309116920-1122.93324-15-0@perl.org
On Wed Jun 22 14:17:04 2011, rurban wrote:
> 2011/6/22 Nicholas Clark <nick@ccl4.org>:
> > On Wed, Jun 22, 2011 at 08:09:30AM -0700, Reini Urban wrote:
> >
> >> Remove huge B dependency from Carp, introduced with 5.14 to detect
> >> incomplete caller override.
> >>
> >> This reduces the memory and run-time footprint in case of errors,
> >> and enables the compiler not to include B.
> >
> > The code was deliberately written *not* to load B.
> >
> > Why does the compiler think that it needs to load B, if there was
> never a
> > C<require B> processed? Does the compiler optimistically load every
> module
> > when it sees a symbol table entry? That feels like a bug.
>
> Unfortunately scanning the deps for the compiler at CHECK is not so
> easy, esp. for modules
> which the compiler uses by itself.
> Initially all modules which are used by the compiler itself are marked
> unused, but when Carp is
> included (which is now included since 5.14 even for perlcc -e1), B is
> added.
> The compiler can only skip compile-time removed code paths, but not
> run-time paths.
> The logic is by checking the symbol tables, all CVs and by
> counter-checking %INC.
>
> A better fix for rafl's caller problem would be a single XS, maybe in
> CORE to return the GV name.
>
> The dependency chain became very unfortunate with 5.14 and is eating
> all our previous
> speed and memory advantages.
> Carp is including now all warnings categories, which are huge.
> m//i or s///i or lc()/uc() are including now all unicode tables which
> are even more huge. There really should be a pragma to check ASCII
> folds only, extending m//a.
> And Carp is including now B which is also huge.
>
> >> --- perl-5.14.1/lib/Carp.pm.orig � � �2011-04-25 00:21:22.000000000
> -0500
> >> +++ perl-5.14.1/lib/Carp.pm � 2011-06-22 09:26:48.000000000 -0500
> >> @@ -98,38 +98,20 @@
> >> � � �}
> >>
> >> � � �my $sub_name = Carp::get_subname( \%call_info );
> >> - � �if ( $call_info{has_args} ) {
> >> - � � � �my @args;
> >> - � � � �if ( � @DB::args == 1
> >> - � � � � � �&& ref $DB::args[0] eq ref \$i
> >> - � � � � � �&& $DB::args[0] == \$i ) {
> >> - � � � � � �@DB::args = (); � �# Don't let anyone see the address
> of $i
> >> - � � � � � �local $@;
> >> - � � � � � �my $where = eval {
> >> - � � � � � � � �my $func � �= $cgc or return '';
> >> - � � � � � � � �my $gv � � �= B::svref_2object($func)->GV;
> >
> > It uses a routine from B inside an eval {} without loading B, so
> that if B
> > *isn't already loaded* it gives the previous behaviour.
> >
> > So I think you're overstating the benefits to say that it will
> reduce the
> > memory footprint of Carp by implying that it removes a B dependency.
>
> True. I didn't see that.
>
> > Likewise, if the code is working as designed if the compiler simply
> doesn't
> > include B/load B/bundle B (however it does it), the eval{} will
> fail, and
> > the fall back code will still produce errors.
>
> Unfortunately the eval is runtime, so I have to compile it in.
> With a BEGIN-time check if B is already included I could live, I
> guess.
> I'll try this out when I have more time.
>
> > Although I wrote this, I don't have any particular attachment to the
> code, so
> > I don't mind if the consensus is to remove it. *But*
> >
> > a: I think that your reasons are not correct.
> > b: Rafl has already reported that this code has proved useful in
> tracing a bug
> >
> > I don't think that removing it brings the benefits you imply. It's a
> small
> > code removal for a larger functionality removal.
>
> Well, everything has two sides, yes.
If we change B::svref_2object($func) to &{"B::svref_2object"}($func)
will that work for you? That way we still get to keep the current behaviour.
Thread Next
-
[perl #93324] [PATCH] Remove B from Carp
by Father Chrysostomos via RT