Removing Moose and the case for Mouse
I thought I'd write my own practical version of Moose::Manual::Unsweetened by converting Hailo away from Moose. The resulting hack passes all of Hailo's tests but not surprisingly it wasn't worth it.
I wanted to see if I could get the startup time of Hailo down since Moose doesn't incur a runtime penalty once all your classes have been constructed. Here's how much time it takes the three version of Hailo to start up and reply to input, and how much (RSS) memory they use:
- Hacky Perl OO: 100ms / 5.6MB
- Mouse: 150ms / 7.4MB
- Moose: 350ms / 12MB
Mouse seems to get a lot of flak within Moose circles for not being a 100% complete Moose implementation. I previously wrote about how you can maintain dual support for Moose and Mouse in a previous posting.
In future programs I'll be using Mouse as the default with a fallback to Moose. It does everything I need from Moose and doesn't suffer from the high startup time / memory use that's frequently cited as an objection to Moose-based applications.
If that doesn't convince you, here's a mouse riding a frog:
Blogging about anything Perl-related I get up to.
I'm not sure how compelling the memory argument is. Memory isn't free, but it's not that expensive. If you launch 100 processes, your Moose version needs approximately 480MB more. That's about $20 if you buy nice ECC ram in 4GB sticks.
Also, besides not being a complete Moose implementation, using Mouse severely restricts what extensions are available. Of course, you could always reimplement even more extensions for Mouse, but is that the best use of programming time?
"If you launch 100 processes, your Moose version needs approximately 480MB more. That's about $20 if you buy nice ECC ram in 4GB sticks."
Actually, that's about $20 a month if you're running these processes on a VPS.
Dave: For most things I completely agree. But the reason I care about this with Hailo is that it's also accessible as a command-line program. Having to wait up to a second for
--helpoutput while loading Moose grinds your disk doesn't make for a friendly program.I think speed matters, even if using Mouse sacrifices some correctness. For my use of Moose (which admittedly, isn't terribly advanced) Mouse does all the things I need, without the speed bump.
I'm mainly just trying to make people more aware of Mouse's existence. There isn't a single mention of it anywhere in Moose's documentation and Mouse's own documentation discourages its use.
MooseX::modules could also be adapted to play nice with Mouse (and other future implementations) if they used Any::Moose. Do we really need to copy/paste code betweenMooseX::andMouseX::*in lieu of making modules compatible with both? Maybe there's a good reason for it that I don't know about.So if the author of Mouse says to use Moose instead...why are you telling people to do the opposite?
That part of Mouse's documentation was added in Mouse 0.20 when Shawn M Moore stopped maintaining Mouse. Mouse is now under new maintainership and the current release is 0.51.
I don't think people should blindly follow my advice and use Mouse. But I'd like to point out that after having used it that I find it a good fit for the sort of projects & code that I write.
I also think it could use some positive advertisement, so I wrote this blog post to do my part to rectify that. That is all.
Fair 'nuff... :-)
No, it's $160 a month to run 2.8GB instance on linode. :)
I was on the fence, but that mouse riding on the frog completely sold me.
There's no question.
I still think people should generally not use Mouse, for whatever my opinion is worth. That said, Goro Fuji is doing a good job maintaining Mouse. It's in good hands now.
Excellent article, but my favorite part was definitely the mouse on top of a frog LOL - they are great buddies apparently
Indeed, every article needs a funny picture!