Is Moose really this slow?

Question

I recently downloaded Moose. Experimentally, I rewrote an existing module in Moose. It seems to be convenient way to avoid writing lots of repetitive code. I ran the tests o

Answer 1

Yes, there's a bit of a penalty to using Moose. However, it's only a startup penalty, not at runtime; if you wrote everything properly, then things will be quite fast at runtime.

Did you also include this line:

__PACKAGE__->meta->make_immutable;

in all your classes when you no Moose;? Calling this method will make it (runtime) faster (at the expense of startup time). In particular, object construction and destruction are effectively "inlined" in your class, and no longer invoke the meta API. It is strongly recommended that you make your classes immutable. It makes your code much faster, with a small compile-time cost. This will be especially noticeable when creating many objects.^{1 2}

However, sometimes this cost is still too much. If you're using Moose inside a script, or in some other way where the compilation time is a significant fraction of your overall usage time, try doing s/Moose/Moo/g -- if you don't use MooseX modules, you can likely switch to Moo, whose goal is to be faster (at startup) while retaining 90% of the flexibility of Moose.

Since you are working with a web application, have you considered using Plack/PSGI?

¹_{From the docs of make_immutable, in Moose::Cookbook::Basics::Recipe7}
²_{See also Stevan Little's article: Why make_immutable is recommended for Moose classes}

Answer 2

Your question is a little deceptive. Yes, Moose has a measurable startup cost, but isn't slow after that. If the startup cost is prohibitive, you can always daemonize your application.

Answer 3

See Moose::Cookbook::FAQ:

I heard Moose is slow, is this true?

Again, this one is tricky, so Yes and No.

Firstly, nothing in life is free, and some Moose features do cost more than others. It is also the policy of Moose to only charge you for the features you use, and to do our absolute best to not place any extra burdens on the execution of your code for features you are not using. Of course using Moose itself does involve some overhead, but it is mostly compile time. At this point we do have some options available for getting the speed you need.

Currently we provide the option of making your classes immutable as a means of boosting speed. This will mean a slightly larger compile time cost, but the runtime speed increase (especially in object construction) is pretty significant. This can be done with the following code:

MyClass->meta->make_immutable();

We are regularly converting the hotspots of Class::MOP to XS. Florian Ragwitz and Yuval Kogman are currently working on a way to compile your accessors and instances directly into C, so that everyone can enjoy blazing fast OO.

On the other hand, I am working on a web application which using Dancer and Moose. Because the application is running as an HTTPD daemon, none of this is really relevant once the server is initialized. Performance seems more than adequate for my requirements on limited hardware or virtual servers.

Using Moose and Dancer for this project has had the added benefit that my small demo application shrank from about 5,000 lines to less than 1,000 lines.

How much stuff you want your app to depend on is one of those trade-offs you have to consider. CGI apps are made more responsive by limiting dependencies.