@public: "mro is currently split into mro.c and a module in ext/mro.  This 
arrangement isn't working in os390, EBCDIC, because of a loader issue.
The EBCDIC porter, Yaroslav Kuzmin, can get it to work in os390 by 
adding the contents of ext/mro.c to ./mro.c, and making ext/mro.xs into 
a dummy.
Is there a reason not to just do this for all platforms, so that it is 
effectively always in core?"
    @syber: "Hello everyone. Several months ago i wrote my thoughts on this topic.
This is what i planned to do.
"
Hello, everyone!
Here's what i'm currently working on
Main issue: unacceptably slow C3 method resolution
  Empty Object/Class method runs 8-10.000.000/s
  Empty Object/Class next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method runs 650.000/s (+ next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4n,
may888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method)
More issues:
  1) We have implicit XS API to call superclass method (cache supported)
      (gv_fetchmeth_pvn with GV_SUPER in flags)
     But we don't have any for next method.
     Perl_call_method("next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method") is a wasteful usage of CPU.
  2) inconsistency of gv_fetchmeth_pvn (entry sub), super method and
next method.
      I'll explain:
      If we call a method, first-CV resolution will always be done
based on stash's mro algorithm (dfs or c3 or custom) because
gv_fetchmeth_pvn uses mro_linear_isa.
      If we call next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method, then next-CV resolution will always be
done using c3 algorithm because mro_nextcan directly calls
S_mro_get_linear_isa_c3. Thus if a class doesn't say 'use mro c3' (a
programmer accidentally forgot to write), first resolution will be
done using DFS, and next using C3. That leads to a hard-to-debug bugs
in a programmer's code.
      If, God forbid, we should call SUPER888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method on a c3 class,
wrong resolution might happen.
    You can see that next method's code (__nextcan in mro.xs) doesn't
actually depend on mro algorithm, the only difference is inside
mro_get_linear_isa.
    So ideally, imho, API should look something like this:
        package MyClassC3;
        use mro 'c3';
        sub func () { $_[0]->NEXT888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method }  # C3 resolution
        package MyClassDFS;
        sub func () { $_[0]->NEXT888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method }  # SUPER (DFS) resolution
    leaving a programmer no chances to shoot his foot.
   We can't change next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method behaviour (make it use class's alg
instead of hardcoded c3), because we'll break compability.
 So my suggestions are:
1) Speedup next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method & Co (see below detailed how)
2) Make explicit API for super and next method
    gv_supermeth_pvn (just a gv_fetchmeth_pvn with GV_SUPER flag)
    mro_nextmeth_pvn
3) Leave SUPER888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method and next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method behaviour as is, add new method key=
word
    (NEXT888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method, super888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method, whatever? ) which does mro
resolution based on mro_get_linear_isa, not on mro_get_linear_isa_c3.
    Add XS API for new keyword: gv_nextmeth_pvn
    Consider next method resolution code independent of mro alg, move
it from ext/mro/mro.xs to mro.c (or gv.c). Leave in mro.xs only
S_mro_get_linear_isa_c3 and XS functions wrappers.
Speeding up next method:
Target: the same speed as class/method initial call (8-10.000.000/s)
or at least comparable.
Steps:
1) Remove pure perl wrapper around XS_mro__nextcan, make next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method
& Co a new optype.
2) remove extremely slow gv_efullname3 call (70% of XS_mro__nextcan
time), replace it with stack buffer + optional malloc if needed.
3) If next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method is located in a real sub, cache it's gv_efullname3
and hash value in OP during Perl_ck_method. In this case we don't need
to __dopoptosub to find a real sub.
    Otherwise (anon sub), leave dopoptosub, name and hash computations
until runtime.
Expected speedup: 10x min
A lot of popular frameworks (DBIx888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4lass for example) use C3. So real
project's boost should be definitely meaningful.
"
P.S. additional problem:
Currently you can't call neither SUPER nor next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method from XS
method, because XS function doesn't create BLOCK scope.
To fix that, code of SUPER and next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method should NOT use BLOCK stack
or PL_curcop to determine current sub. Instead of this they should use
CV* of the current sub which is passed to XS function or perl
function.
2014-10-17 12:34 GMT+04:00 Yaroslav Kuzmin <email_address>:
<quote>
nction funA2()
 xlc (and in gcc 2.xx).
ster(), but function
lem.
=D0=B5=D0=BD=D0=B8 Nicholas Clark <email_address>
=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3. 13:10
@gmail.com; Yaroslav Kuzmin
't
est
ring
he
ons
as
=3D=3D=3D=3D=3D=3D=3D=3D
m MA 02451 =E2=96=A0 +1-215-451-8829 =E2=96=A0 +1-215-451-8829
m
balSubscriptionManagementEmailFooter_SubscriptionCenter.html
cy
=3D=3D=3D=3D=3D=3D=3D=3D
=20
Oleg Pronin,
CTO, Co-Founder,
Crazy Panda LTD
CP Decision LTD"
    @syber: "2014-10-21 17:06 GMT+04:00 Leon Timmermans <email_address>:
<quote>
s
However, it does work that way at the moment.
{
    package ABC;
    use mro 'c3';
    sub meth { shift->next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method(@_); }
    *meth1 =3D *meth;
    *meth2 =3D \&meth;
}
my $o =3D bless {}, 'ABC';
eval { $o->meth; }; say $@;
eval { $o->meth1; }; say $@;
eval { $o->meth2; }; say $@;
No next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method 'meth' found for ABC at
/usr/local/perl5.20.1/lib/5.20.1/x86_64-linux/mro.pm line 27.
No next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method 'meth' found for ABC at
/usr/local/perl5.20.1/lib/5.20.1/x86_64-linux/mro.pm line 27.
No next888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4method 'meth' found for ABC at
/usr/local/perl5.20.1/lib/5.20.1/x86_64-linux/mro.pm line 27.
__next_can finds closest CV* on stack that has a name and uses it.
=20
Oleg Pronin,
CTO, Co-Founder,
Crazy Panda LTD
CP Decision LTD"
{'source': 'USENET', 'other_information': '{"reply_count": 2, "forum_name": "perl.perl5.porters.20150608.mbox"}', 'file': 'data/output/usenet-perl.perl5.parquet'}