Front page | perl.perl5.porters |
Postings from January 2003
On Sun, Jan 19, 2003 at 11:00:51PM +0000, Nicholas Clark wrote:
> On Sun, Jan 19, 2003 at 10:24:58PM +0100, Rafael Garcia-Suarez wrote:
> > - cop->op_private = (PL_hints & HINT_BYTE);
> > + cop->op_private = (PL_hints & HINT_PRIVATE_MASK);
[snip]
> > The only thing that changes is the value of op_private for COPs.
> > This value is then tested in pp_dbstate, which replaces pp_nextstate
> > when run under the debugger.
>
> The two things I don't understand
>
> 1: The above change seems to relate only to hints. Yet the profiling suggested
> that restore_magic is now called about 23 million times, about 23 million
> more than previously. How does changing hints increase the amount of
> magic?
Because pp_dbstate() looks like this:
PP(pp_dbstate)
{
PL_curcop = (COP*)PL_op;
TAINT_NOT; /* Each statement is presumed innocent */
PL_stack_sp = PL_stack_base + cxstack[cxstack_ix].blk_oldsp;
FREETMPS;
if (PL_op->op_private || SvIV(PL_DBsingle)
|| SvIV(PL_DBsignal) || SvIV(PL_DBtrace))
{
.... call DB::DB ....
ie if op_private is non-zero, call DB:::DB for every single statement -
hence the zillions of extra function calls your profiling shows up.
Or to put it another way, putting hints in op_private is inadvertently
causing the debugger to single-step every statement.
> 2: What other things should break without this hints change?
> So what sort of regression tests should we have for them?
>
> > (Another fix is of course to stop storing hints in COP.op_private.)
I guess the other thing to do is to stop pp_dbstate() testing
op_private; or find out why it does it, and only test the right bit(s).
Dave.
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark.