I want mop rest capability to define fast accessor
In Perl, accessor access is about 30 times slower than direct access. For example,
# Accessor access $obj->title; # Direct access $obj->{title};
"$obj->title" is about 30 times slower than "$obj->{title}". In current perl, we can't replace accessor access with direct access in general way.
but in mop, we can distinguish method and attribute. If so, we may replace accessor access with direct access. I want mop to rest capability to define this fast accessor.
Steven said "$self->title" is overhead, but if fast accessor is implemented, this is no longer overhead, and we can access attribute by unified way without performance overhead.
We must access attribute by accessor in subclass. For example.
class Point3D extend Point { has $z; method clear { $self->x(0); $self->y(0); $z = 0; } }
We can't write the following way in mop.
class Point3D extend Point { has $z; method clear { $x = 0; $y = 0; $z = 0; } }
If so, it is clean that we access attribute by accessor in all case.
class Point3D extend Point { has $z is rw; method clear { # unified way to access attribute $self->x(0); $self->y(0); $self->z(0); } }
I want mop to rest capability to define fast accessor which interpret $self->x as $self->{x}
In case of inside-out objects, $self->x is not the same as $self->{x}, but rather something like $register->{x}{refaddr $self}.
Yuki - What you are asking for is not something that should be part of the mop, it would be part of the Perl compiler itself. This would be similar to how the Perl interpreter optimizes constants, by detecting a pattern in the code and then optimizing it. The same could theoretically be done for mop accessors since they would follow a specific pattern.
See also: Steffen Müller's scary/awesome AutoXS.
@Toby: What you really want is using Class::XSAccessor (which is the actual accessor implementation that AutoXS uses) directly. AutoXS was a fun experiment and I hope the docs say something to that effect.
IIRC Moo can use Class::XSAccessor for some of the basic accessor types automatically if it's installed.
See https://blogs.perl.org/users/rurban/2011/06/how-perl-calls-subs-and-methods.html on "Optimization of static methods, e.g. Class->new" the opt_methods patch.
With typed methods, readonly packages and @ISA you'll get this optimization also for dynamic methods.
In Moose/mop they called it immutable, but don't use these optimizations.
Yes, I know it. This entry is one example to describe method accsess and direct access.
Current, Perl compiler can't distinguish normal method and accessor. so compiler can't optimize method.
If mop is implemented, Perl can know that method is normal method or accessor. If so, Perl can replace accessor access with direct access if accessor is simple read-write access.
This is relevant to mop. If mop don't exists, Perl can't distinguish normal method and accessor.
>See also: Steffen Müller's scary/awesome AutoXS.
I don't mean that accessor is replaced with XS accessor. I mean that accessor is replaced with direct access.
>See https://blogs.perl.org/users/rurban/2011/06/how-perl-calls-subs-and-methods.html on "Optimization of static methods
What I wrote in this entry is that accessor is replaced with direct access, not with optimized method.
For example, See the following accessor.
$self->x is same as $self->{x}.
$self->x(1) is same as $self->{x} = 1.
so accessor access $self->x can be replaced with direct access $self->{x}.
Yuki -
You really should look into XSAccessor. If you like it, you should push its use. It is *faster* than direct hash access due to crazy op tree fiddling. Seriously, check it out.
As for what you want, what happens when I create a derived class that overrides the accessor? In that case, would your optimizations kill my derived class's overrides? Would it have to compile a separate chunk of code especially for my class so as *not* to kill my class's overrides? I totally understand what you want, but I just want to make sure you realize it's a tough problem.
No, it's slower than direct hash access, though not by an awful lot...
Steffen, yes, I'm aware of Class::XSAccessor. I even ported the Moo auto-XS-acceleration stuff to Moose.
My mention of AutoXS was meant as an example of how it is possible to recognise patterns in the op tree and then replace them with something faster.
@Toby Inkster: Gotcha. For a more serious attempt at matching things to optimize, maybe have a look at https://github.com/tsee/jit-experiments
I do benchmark.
XS accessor is much faster than I have expected. I had thought function access is much slower than direct access.
This topic is meaningless. I end my argument.
Thank you for many information.
@Yuki: Technically, Class::XSAccessor accessors are no longer full function calls after they're first invoked by a given call site. They are an entersub-OP alike custom OP. The whole thing is quite devious. Most cleverness was contributed by chocolateboy.
thank you.
I hadn't known the existence of entersub-OP.
I'm glad to learn entersub-OP.