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 of the module, and I noticed it was a bit delayed. I profiled the code with -d:DProf and it seems that just including the line

no Moose;

in the code increases the running time by about 0.25 seconds (on my computer). Is this typical? Am I doing something wrong, did I misinstall it, or should we really expect this much delay?

Answer 1

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 2

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/Mouse/g -- if you don't use MooseX modules, you can likely switch to Mouse, 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 mod_perl?

¹_{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 3

Using Moose pulls in a lot of stuff which needs to be compiled. Therefore, startup time is going to suffer. In that regard, Moose is no different than any other module with a lot of dependencies. Therefore, it would not be good choice to for a CGI application.

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.

On the other hand, most of my CGI scripts start with a sleep rand 3; ;-)