Shlomi,
On Jun 1, 2008, at 8:57 AM, Shlomi Fish wrote:
I said that I'd like to convert Test-Run to Moose. Well, now I'm in
the midst of the translation - many tests fail, but the problem is
that the tests now run much more slowly. It is a noticable difference,
that makes running the tests unbearable.
I have found that this is typical of sufficiently complex
Class::Accessor modules, the coding style promoted by Class::Accessor
seems to not match well with Moose. In particular where passing undef
values into the accessors is concerned (which is almost certainly
where your test failures are coming from) Moose will not allow this
(a "Str" type is not "a string, but possibly undef too"). Also proper
use of lazy & default/builder with Moose will help make instance
generation quicker, especially in the cases where you don't always
need every slot to be initialized. In those cases too, using the
"predicate" option (documented in Class::MOP::Attribute) will help as
well. Here is an example of this actually:
Class::Accessor version:
{
package Foo;
__PACKAGE__->mk_accessors('bar');
}
my $foo = Foo->new; # no "bar" initialized
if ($foo->bar) { ... } # this check is cheap, because your just
checking the accessor
Moose version:
{
package Foo;
use Moose;
has 'bar' => (is => 'rw', lazy => 1, default => 'FOO::BAR',
predicate => 'has_bar');
}
my $foo = Foo->new; # no "bar" initialized
if ($foo->bar) { ... } # this check is NOT cheap, because your
forcing the deferred value in bar to be created
if ($foo->has_bar) { ... } # this check *is* cheap, because your
just checking slot existence
Now, in the above example thats not really that much of a difference,
but if 'bar' were are large complex data structure or some
expensively computed value, then it would make a huge difference.
It should be pointed out that the most recent Moose/Class::MOP
release has a speedup which showed approx. 20-25% better performance,
so things are improving. And people have seen anything from a 3x to
10x times performance increase by making their classes immutable
(depending largely on the complexity of the classes I think, no one
has cared enough to benchmark and figure it out).
The problem as I see it is that I'm using Plug-ins instead of Roles
and that I didn't finalise the class. Of course, I'd rather not
finalise the class, or ditch away plug-ins.
I think perhaps you misunderstand the use of the "immutable" feature.
First, it is not finalizing, in the C# sense of the word, where it
prohibits subclassing and such. Making a class immutable means that
the metaclass can longer be altered, it allows Moose to then create
an inlined constructor as well as memoize several of the more
commonly needed bits of data in the metaclass. This is much less
restrictive then you might think, and unless you are doing lots of -
>meta hacking, you will never need to care.
I am not sure how you are doing plugins, but there are two ways to go
about this in the Moose world utilizing roles.
1) Compile-time
This is plugins that you can know about during class construction
time, and are *class* specific. So you simply create your class,
applying the roles for the plugins. Often times, this is enough and
runtime pluggable-ness is really overkill and not actually necessary.
The key thing about this is that it is *class* specific, meaning you
will want several instances of a specific class (with a specific set
of plugins applied to it) in your application. This may require
creating a few extra subclasses, but really if your application
doesn't require arbitrary combinations of plugins applied to
arbitrary instances of varying classes, then this may actually help
increase the clarity of you design.
Now, since this is all compile-time defined, obviously it does not
hamper making a class immutable.
2) Run-time
Now, sometimes your application design *does* require arbitrary
combinations of plugins applied to arbitrary instances of varying
classes, in this case you really do need a plugin system. In this
case you can still use roles, you just apply them to an instance
instead of to a class. Of course this is a more expensive operation
because Moose needs to create an anon-class for you and apply the
role to that, but you asked for it, and so you need to pay the cost.
Moose will cache specific combinations of class+roles and try to
reuse the anon-classes if possible, and it does help if you apply all
the roles at once and not in succession.
Now, even though this is all done at runtime, you can still make your
underlying classes immutable and get some of the performance benefits
it provides.
And naturally, Moose is
also making many run-time checks that are not present in my old
Class-Accessor and are not really necessary for me. As much as I
appreciate type-checking for instance members, I'm disciplined enough
for it not to matter much.
So just remove the types, it is that simple since they are entirely
optional. In fact, the accessor generated by Moose for this:
has foo => (is => 'rw');
if *faster* the the typical Class::Accessor version since it never
creates a lexical $self, and just uses $_[0] instead. Moose does as
much as it can to only make you pay for the features you use, but it
cannot remove the cost of features you use, but just don't really
want ;)
So Moose seems impressive, but an overkill for Test-Run's needs.
I think perhaps you have not given Moose enough of a chance, and that
your making this judgement before properly understanding what Moose
can provide for you. Any powerful tool (like Moose), if not properly
used, will seem like overkill.
So unless Moose will become faster, I won't be able to use it in
Test-Run, and will have to rely on Class-Accessor and the additional
logic I've built on top of it.
Moose is becoming faster and that is one of our primary goals right
now. However in your case, by using type checks you don't want and
not making your classes immutable, *you* are the one slowing your
application down. The tools are right in front of you, you need only
to use them.
From what I've heard of CPython, they
often re-implemented Python libraries code in C to make them faster.
Perhaps the Perl world should follow suit.
We have some C/XS in Class::MOP and the inclusion of that it provided
our last major speed boost actually. There are possibly a few other
places we could recode in C/XS that would provide us some more
benefits, but since I am not (and never will be) a C programmer, all
I can say is
... patches welcome :)
- Stevan
