Re: [perl #81332] 744aaba059 bloats the B compilers

[Reini Urban]

2011/2/13 Nicholas Clark <ni...@ccl4.org>:
> On Sun, Feb 13, 2011 at 01:15:33PM -0800, Father Chrysostomos via RT wrote:
>> On Mon Dec 27 01:52:01 2010, rurban wrote:
>> > This is a bug report for perl from rur...@cpan.org,
>> > generated with the help of perlbug 1.39 running under perl 5.10.1.
>> >
>> >
>> > -----------------------------------------------------------------
>> > 744aaba059 moved the B bootstrap'ing from INIT to BEGIN, which is a
>> >    big
>> > problem in all B compilers, since any compiler does not know if a B
>> > constant is needed inside the users code or just imported by using the
>> > compiler.
>> > E.g. every compiled .plc bytecode file is now 13K bigger,
>> > all B constants are imported now. Similar for the other compilers.
>> >
>> > The only reason of the move was to avoid to stub B::OPf_KIDS.
>> > Please revert.
>>
>> Does anyone see any reason I should not revert this?
>
> I don't doubt that they are bigger, but I'm curious about why the ordering of
> the loading *does* make the difference. I don't believe that the diagnosis
> in the bug report is completely correct because the change *doesn't* move the
> laoding from INIT time. (It does move it to BEGIN). Module body code runs
> immediately at require time, which is much earlier than INIT.

The XS part is now loaded earlier which adds all constants and a
lot more to the B namespace seen by the compilers.

This adds a lot of unneeded code the all compiled code, which is esp.
troublesome for Bytecode, but also for the only advantage of B::C code,
faster initialization.
--
Reini Urban

[Reini Urban]

2011/3/19 Nicholas Clark <ni...@ccl4.org>:

> On Tue, Feb 15, 2011 at 11:55:06PM +0000, Reini Urban wrote:
>> 2011/2/13 Nicholas Clark <ni...@ccl4.org>:
>> > On Sun, Feb 13, 2011 at 01:15:33PM -0800, Father Chrysostomos via RT wrote:
>> >> On Mon Dec 27 01:52:01 2010, rurban wrote:
>> >> > This is a bug report for perl from rur...@cpan.org,
>> >> > generated with the help of perlbug 1.39 running under perl 5.10.1.
>> >> >
>> >> >
>> >> > -----------------------------------------------------------------
>> >> > 744aaba059 moved the B bootstrap'ing from INIT to BEGIN, which is a
>> >> >    big
>> >> > problem in all B compilers, since any compiler does not know if a B
>> >> > constant is needed inside the users code or just imported by using the
>> >> > compiler.
>> >> > E.g. every compiled .plc bytecode file is now 13K bigger,
>> >> > all B constants are imported now. Similar for the other compilers.
>> >> >
>> >> > The only reason of the move was to avoid to stub B::OPf_KIDS.
>> >> > Please revert.
>> >>
>> >> Does anyone see any reason I should not revert this?
>> >
>> > I don't doubt that they are bigger, but I'm curious about why the ordering of
>> > the loading *does* make the difference. I don't believe that the diagnosis
>> > in the bug report is completely correct because the change *doesn't* move the
>> > laoding from INIT time. (It does move it to BEGIN). Module body code runs
>> > immediately at require time, which is much earlier than INIT.
>>
>> The XS part is now loaded earlier which adds all constants and a
>> lot more to the B namespace seen by the compilers.
>

> That code is always loaded by the time that caller's 'require B' completes.
> What the commit changed was that it now runs inside a BEGIN block midway
> through the compilation of the code in B.pm, rather than running immediately
> after compilation. But it's all going to happen anyway as part of loading B.
>
> I had assumed that it was significant as it was in a BEGIN block, rather than
> regular code, but:

>
>
>> This adds a lot of unneeded code the all compiled code, which is esp.
>> troublesome for Bytecode, but also for the only advantage of B::C code,
>> faster initialization.
>

> I can't seem to replicate this. "before" and "after" are without and with
> the change (ie 4bf035ef9384dfbe and 744aaba0598b4500 respectively)
>
> /home/nick/Sandpit/after/bin/perl5.13.6 -MO=Bytecode,-H,-b,-oHWa -e 'print "Hello world\n"'
> Untagged opnames: rvalues rkeys transr reach
> -e syntax OK
> $ /home/nick/Sandpit/before/bin/perl5.13.6 -MO=Bytecode,-H,-b,-oHWb -e 'print "Hello world\n"'
> Untagged opnames: rvalues rkeys transr reach
> -e syntax OK
> $ ls -l HW?
> -rw-r--r-- 1 nick nick 613 Mar 19 11:08 HWa
> -rw-r--r-- 1 nick nick 614 Mar 19 11:08 HWb
>
>
> For the case of "hello world" both produce small bytecode, which differs only
> in the shebang line:
>
> $ diff -a  HWa HWb
> 1c1
> < #! /home/nick/Sandpit/after/bin/perl5.13.6
> ---
>> #! /home/nick/Sandpit/before/bin/perl5.13.6
>
>
> And neither are 13K large, let alone 13K larger. If I bytecompile installperl,
> it's 113296 and 113297 bytes respectively (again, the shebang line)
> Compiling 'use B;' doesn't make a difference.
>
> $ ls -l useB?
> -rw-r--r-- 1 nick nick 4334 Mar 19 12:40 useBa
> -rw-r--r-- 1 nick nick 4335 Mar 19 12:39 useBb
>
> The only thing that I can find that differs is if I compile B itself.
> I have add fb6620c6d4bfa241 to fix my bug of b2adfa9b5e1682df:
>
> $ /home/nick/Sandpit/before+fb66/bin/perl5.13.6 -MO=Bytecode,-H,-m,-oBb /home/nick/Sandpit/before+fb66/lib/perl5/5.13.6/x86_64-linux/B.pm
> Untagged opnames: rvalues rkeys transr reach
> /home/nick/Sandpit/before+fb66/lib/perl5/5.13.6/x86_64-linux/B.pm syntax OK
> $ /home/nick/Sandpit/after+fb66/bin/perl5.13.6 -MO=Bytecode,-H,-m,-oBa /home/nick/Sandpit/after+fb66/lib/perl5/5.13.6/x86_64-linux/B.pm
> Untagged opnames: rvalues rkeys transr reach
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> Upgrading shift BASEOP to ...
> /home/nick/Sandpit/after+fb66/lib/perl5/5.13.6/x86_64-linux/B.pm syntax OK
> $ ls -l B?
> -rw-r--r-- 1 nick nick 51948 Mar 19 13:41 Ba
> -rw-r--r-- 1 nick nick 24390 Mar 19 13:41 Bb
>
>
> So 744aaba059 certainly makes the compiled B bigger. But I can't replicate
> your report that it makes *every* compiled .plc bytecode file is now 13K
> bigger.
>
> What did I miss?

You missed that I patched the compiler with B-C-1.30
to ignore any B symbols not to bloat the compiled code.

For Bytecode it is in B::HV::bwalk
...
# B since 5.13.6 (744aaba0598) pollutes our namespace. Keep it clean
# XXX This fails if our source really needs any B constant
unless ($] > 5.013005 and $hv->NAME eq 'B') {
$v->ix(1) if desired $v;
}
}
else {
if ($] > 5.013005 and $hv->NAME eq 'B') { # see above. omit B prototypes
return;
}

You can remove those checks:

$v->ix(1) if desired $v;
} else {
...
--
Reini Urban
http://phpwiki.org/           http://murbreak.at/