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?

Dikmen

0.25 seconds. Once. It's the end of the world! Run! – Dogvane

0.25 seconds is a remarkably long time for a computer program to spend initializing, hobbs. – Dikmen

When lumped in with loading configs from files and the DB, setting up network interfaces etc, it's not really significant, if your program is going to be running for many hours or days, like a web application. – Mabel

My program is a web application, but it is not going to be running for many hours or days, it will be run once per request. The 0.25 delay is a serious deficiency for that. Why is everyone being so defensive, by the way? Whatever happened to "answering the question"? The question is, should I expect this delay, or did I do something wrong? It seems like the answer is "yes, you should expect this delay". – Dikmen

@Ether: wouldn't this penalty be especially significant in the case of a web app? It's going to get hit with a ¼-second penalty for each request that it handles. – Macy

Kino: in a word, the answer is "yes", but the more lengthy answer is "but there are several ways around that". – Mabel

@intuited: that's one of the big advantages of using mod_perl. – Mabel

@Mabel no one in the right mind uses mod_perl for web apps... It is for extending Apache with Perl, not building websites. Use FCGI. – Glenglencoe

@Evan: Personally I build websites by extending Apache with Perl, but YMMV :) – Mabel

I can't believe I upvoted EC. But seriously, FastCGI is the most sane option. Writing websites in mod_perl has serious portability implications. – Pipit

writing websites with mod_perl has serious insanity implications. These days plack is the way to go. – Furculum

Absolutely. I swear that wasn't me writing those comments about mod_perl, honest!!!!!!111!!!oneoneone :) TO CLARIFY - this is one of the advantages of any web framework that starts up and then stays up for a long amount of time to service many requests. mod_perl is not the best option here - Mojolicious, Catalyst and Dancer are all better choices and all run on the Plack/PSGI framework which is much more sane than mod_perl. – Mabel

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}

Mabel

Ether, I deleted all the other Moose stuff and just forgot to delete the final line "no Moose" and yet still got this 0.25 second delay. As for Mouse, how much faster is it? – Dikmen

Sometimes much faster. There's rarely a good reason to not make your classes immutable (it's one of those things where you should only do so if you know why, and understand the drawbacks and ramifications.) – Mabel

$ time perl -Moose -E'has qw/foo isa Int is rw/; __PACKAGE__->meta->make_immutable if @ARGV; push @_, Class->new for 1..100_000; print scalar @_', then run the same thing just append a 1 as an argument. You could use Benchmark(.pm), but sometimes it isn't even close. – Glenglencoe

Ether: Mouse's goal is to provide faster startup times, not to "be faster". A secondary (related!) goal is to have fewer dependencies. – Syndesmosis

Err, and make_immutable will AIUI make startup slower not faster. – Syndesmosis

@ysth; aye; I'll edit to make that more clear. immutability == slower startup but faster runtime; Mouse == faster startup, but less flexibility. – Mabel

Actually Mouse's original goal was to teach Sartak how to write a Meta Protocol. Second to that was a low dep Moose without all the "Meta" overhead. Sartak then found that the "Meta" was the powerful part of Moose and moved on and someone else picked up Mouse. – Carsoncarstensz

There are some MouseX modules to match MooseX modules, and some MooseX modules can be used with Mouse when you combine it with Any::Moose. It should also be noted that not only is Mouse faster to startup than Moose, it uses less memory. Part of Mouse's speed comes from it being partially implemented in XS (something we're still waiting for from Moose) – Saucedo

@MkV: some of Moose and Class::MOP is in XS. – Mabel

Ether: yeah, but that is mostly for reasons of magic, not performance – Saucedo

The advice about Mouse is outdated. Use Moo instead for startup time sensitive stuff. – Furculum

@Furculum yes, Moo is the way to go! I've edited my answer. – Mabel

Answer 2

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.

Greywacke

+1 This is how I've been writing prototype or small web apps for past couple of years (except s/Dancer/Squatting/). Add a Reverse Proxy (en.wikipedia.org/wiki/Reverse_proxy) and never need to worry about CGI again :) – Autointoxication

@Sinan - could you please clarify the last line? Was that just a joke or some Yoda-like spark of wisdom that i'm just not grokking? – Babi

"Using Moose pulls in a lot of stuff which needs to be compiled" seems misleading. Moose is slower to start because of its meta construction/introspection/hook stuff, not because it compiles code. Lots of modules in common usage with CGI.pm compile as much or even more code. – Tousle

@Babi Will have to explain some other time, but it is not some Yoda like wisdom. – Ebbie

@Sinan Out of curiosity, what do you consider to be moderate hardware? The sleep thing is a joke, right? :) – Streptococcus

Removed reference to sleep in CGI scripts. – Ebbie

Answer 3

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.

Syndesmosis

Why is it deceptive? I had no idea Moose was this slow until yesterday, and I was fairly surprised by it. – Dikmen

Also, in this case I cannot daemonize my application, and that would bring in a host of considerations like memory and file management. – Dikmen

@Kinopiko, ysth is arguing the term slow hardly invokes "compile time" costs... You wouldn't say a KDE 4 is slow because it takes 9 hours to compile. And, you wouldn't say Linux is slow because of the time to run init scripts... I'm not agreeing with ysth, I'm just explaining what I believe is his argument. – Glenglencoe

@Kinopiko: if you look at the source for Moose::Meta::Class, Class::MOP::Class, Moose::Meta::Attribute and Class::MOP::Attribute you will not be surprised :) – Mabel

You said it again: "Moose [is] slow"...*you* know you mean startup time, but someone else won't unless you clarify. – Syndesmosis

See for instance Ether's answer where s/he gives you advice that will make Moose faster at the expense of longer startup. – Syndesmosis

But I don't actually mean startup time. My whole program takes about 0.02 seconds to run to completion (i.e. finish what it's doing and exit). Hence 0.25 seconds is a lot. – Dikmen

@Kinopiko - you're still talking about startup time (compile time) and the analogy still holds true: it takes 9 hours to compile KDE even if you just want to get on Konsole and find out the kernel version, which doesn't make KDE slow... Though you're arguing here that it is valid to say KDE is slow and leaving out if all you want to is get at the kernel version on a fresh install, other than not really having much to do with slow, it is hardly the normal use case for KDE anyway. – Glenglencoe

With Perl it's not possible to run a program without compiling it, so that is a poor analogy. – Dikmen

I have to wonder why you are using OO at all for what sounds like a very procedural problem. :) – Syndesmosis

@Kinopiko: I don’t think there is any deception at all. It’s well-known and in the docs that Moose has a startup hit. – Tousle

@Ashley: where did I say there was any deception? – Dikmen

I said there was deception, in this question's phrasing, not in the Moose docs. – Syndesmosis

I think the real question is "how fast is Moose?" and if that's fast enough for a specific application... there's no reason to be defensive: people with large applications need to know just how fast their tools are. – Streptococcus

@SoloBold: you are missing the point. "how fast is Moose" can mean two very different things and they have different answers. this isn't being defensive, this is trying to help people to the information they need. – Syndesmosis