On 9/11/07, Rick Delaney <rick bort.ca> wrote:
> On Sep 11 2007, Brandon Black wrote:
> > On 9/11/07, hvcrypt.org <hvcrypt.org> wrote:
> > > "Brandon Black" <blblackgmail.com> wrote:
> > > :[...] The behavior of the current base
> > > :and the proposed change is different even
without exceptions (although
> > > :in ways you wouldn't think a sane module
would care about, but
> > > :still...). When you do the following with
the current base.pm:
> > > :
> > > :perl -wle 'package AA; ISA=();
package BB; use base qw/AA/; package
> > > :CC; use base qw/BB AA/; package main; print
join(q{,}, CC::ISA)'
> > > :
> > > :It prints just "BB". CC::ISA
does not contain "AA" even though it
> > > :was explicitly asked for. This is due to
the "next if
> > > :$inheritor->isa($base)" line. With
the proposed push-all-at-once
>
> Yes, I completely missed the significance of this
line.
>
> > > :logic, CC::ISA would instead be qw/BB AA/ as
asked for.
> > >
> > > I think that could be fixed just by replacing
the check with:
> > > next if grep $_->isa($base),
($inheritor, isa_classes);
> > >
> >
> > Hmmm yeah that should have the same effect as the
original I think.
>
> It would, although your point that some other MRO might
get tripped up
> by this fudging of ISA is still valid. And of
course there's still the
> open question of how useful this optimization is
anyway.
>
Your open question applies to both optimizations on the
table (the
existing ->isa() optimization and the proposed
push-all-at-once one).
The ->isa() optimization is definitely not useful in
5.9.5+, as the
mro code does the same sort of optimization internally, and
goes much
further with the idea. Even on older perls, assuming the
common case
of ISAs and method lists being static after BEGIN is
done, the ISA
tree would only be searched on the first invocation of each
method,
and the method to call is cached thereafter, so I suspect
the impact
of the optimization is minimal in the vast majority of
cases.
Then again in the "common" case the whole ISA push
thing on 5.9.5+
probably doesn't matter to most real-world code either. The
main
reason I've been pushing (sorry  ) for
optimizing out unnecessary
MRO recalculations is for the sake of C3-using projects. As
compared
to the dfs linearization, the C3 one is *really* expensive.
Back before this effort started, I had test cases of
DBIx::Class
Schemas (with hundreds of database tables represented as
classes with
a fairly complex C3 hierarchy underneath it all) that were
taking ~30
seconds just to do "perl -MMy::Schema -e1", and
the overwhelming
majority of that time was being spent in
Class::C3/Algorithm::C3
calculating MRO linearizations. With the new mro code in
5.9.5+,
these sorts of test cases had their times cut by more than
an order of
magnitude. Things like doing the
"push-all-at-once" optimization in
base.pm really help out in that sort of extreme scenario
more than in
the common case.
-- Brandon
|