11

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?

  • 1
    0.25 seconds. Once. It's the end of the world! Run! – hobbs Jul 02 '10 at 01:11
  • 5
    0.25 seconds is a remarkably long time for a computer program to spend initializing, hobbs. –  Jul 02 '10 at 01:21
  • 2
    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. – Ether Jul 02 '10 at 01:26
  • 15
    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". –  Jul 02 '10 at 01:29
  • @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. – intuited Jul 02 '10 at 01:39
  • 1
    Kino: in a word, the answer is "yes", but the more lengthy answer is "but there are several ways around that". – Ether Jul 02 '10 at 01:39
  • 4
    @intuited: that's one of the big advantages of using mod_perl. – Ether Jul 02 '10 at 01:41
  • 5
    @Ether no one in the right mind uses mod_perl for web apps... It is for extending Apache with Perl, not building websites. Use FCGI. – Evan Carroll Jul 02 '10 at 01:45
  • 3
    @Evan: Personally I build websites by extending Apache with Perl, but YMMV :) – Ether Jul 02 '10 at 01:46
  • 4
    I can't believe I upvoted EC. But seriously, FastCGI is the most sane option. Writing websites in mod_perl has serious portability implications. – Kent Fredric Jul 20 '10 at 16:23
  • writing websites with mod_perl has serious insanity implications. These days plack is the way to go. – singingfish Feb 19 '15 at 05:31
  • 2
    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. – Ether Feb 19 '15 at 17:27

3 Answers3

20

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?

1From the docs of make_immutable, in Moose::Cookbook::Basics::Recipe7
2See also Stevan Little's article: Why make_immutable is recommended for Moose classes

Ether
  • 53,118
  • 13
  • 86
  • 159
  • 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? –  Jul 02 '10 at 01:22
  • 3
    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.) – Ether Jul 02 '10 at 01:24
  • 2
    `$ 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. – Evan Carroll Jul 02 '10 at 01:59
  • 2
    Ether: Mouse's goal is to provide faster startup times, not to "be faster". A secondary (related!) goal is to have fewer dependencies. – ysth Jul 02 '10 at 02:46
  • 2
    Err, and make_immutable will AIUI make startup *slower* not faster. – ysth Jul 02 '10 at 02:48
  • 1
    @ysth; aye; I'll edit to make that more clear. immutability == slower startup but faster runtime; Mouse == faster startup, but less flexibility. – Ether Jul 02 '10 at 03:08
  • 7
    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. – perigrin Jul 02 '10 at 03:08
  • 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) – MkV Jul 02 '10 at 12:28
  • 1
    @MkV: some of Moose and Class::MOP is in XS. – Ether Jul 02 '10 at 16:20
  • Ether: yeah, but that is mostly for reasons of magic, not performance – MkV Jul 09 '10 at 18:23
  • 1
    The advice about Mouse is outdated. Use Moo instead for startup time sensitive stuff. – singingfish Feb 19 '15 at 05:29
  • @singingfish yes, Moo is the way to go! I've edited my answer. – Ether Feb 19 '15 at 17:56
12

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.

Community
  • 1
  • 1
Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
  • 1
    +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 (http://en.wikipedia.org/wiki/Reverse_proxy) and never need to worry about CGI again :) – draegtun Jul 02 '10 at 19:49
  • @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? – DVK Feb 12 '11 at 20:46
  • "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. – Ashley Feb 12 '11 at 21:38
  • @DVK Will have to explain some other time, but it is not some Yoda like wisdom. – Sinan Ünür Feb 14 '11 at 12:37
  • @Sinan Out of curiosity, what do you consider to be moderate hardware? The sleep thing is a joke, right? :) – wprl Mar 25 '11 at 01:12
  • Removed reference to `sleep` in CGI scripts. – Sinan Ünür Mar 26 '11 at 22:33
6

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.

ysth
  • 96,171
  • 6
  • 121
  • 214
  • 2
    Why is it deceptive? I had no idea Moose was this slow until yesterday, and I was fairly surprised by it. –  Jul 02 '10 at 01:22
  • Also, in this case I cannot daemonize my application, and that would bring in a host of considerations like memory and file management. –  Jul 02 '10 at 01:25
  • 8
    @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. – Evan Carroll Jul 02 '10 at 01:49
  • 1
    @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 :) – Ether Jul 02 '10 at 01:57
  • 5
    You said it again: "Moose [is] slow"...*you* know you mean startup time, but someone else won't unless you clarify. – ysth Jul 02 '10 at 02:41
  • 1
    See for instance Ether's answer where s/he gives you advice that will make Moose faster at the expense of longer startup. – ysth Jul 02 '10 at 02:52
  • 2
    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. –  Jul 02 '10 at 03:48
  • 2
    @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. – Evan Carroll Jul 02 '10 at 15:22
  • 1
    With Perl it's not possible to run a program without compiling it, so that is a poor analogy. –  Jul 02 '10 at 16:35
  • 1
    I have to wonder why you are using OO at all for what sounds like a very procedural problem. :) – ysth Jul 02 '10 at 17:00
  • @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. – Ashley Feb 12 '11 at 21:41
  • @Ashley: where did I say there was any deception? –  Feb 16 '11 at 05:44
  • *I* said there was deception, in this question's phrasing, not in the Moose docs. – ysth Feb 16 '11 at 06:08
  • 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. – wprl Mar 25 '11 at 01:17
  • @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. – ysth Mar 25 '11 at 04:17