Re: Moose speed and schedule
[email protected] (Jonathan Swartz)
| Newsgroups | perl.moose |
|---|---|
| Message-ID | <[email protected]> |
>> >> Ok! That's good to know. I can't afford to be that much on the >> bleeding edge for this project, but I'll happily try out the next >> CPAN release when it's available. > > Well, I won't lie to you, Moose itself is still pretty bleeding > edge, so in some ways, you are already out here with us anyway ;) > > But I can appreciate not wanting to actually *hang* over the edge. > You understand perfectly. I am another one of those folks for whom Ruby is extremely tempting. Having a great class system helps reduce the longing, and it is worth being out on the edge somewhat for that. > >> Have you thought about some global flag, or at least a per-class >> flag, to enable/disable type constraint checking? It would make >> sense to enable type checking for development servers and disable >> for production servers. > > I have pondered this, but to be honest, I am not a fan of "turning > off" type checking, it feels to me like taking your seatbelt off > once you merge onto the freeway. It would also mean removing type > coercion as well since they are dependent upon one another, so for > that reason alone, it won't be a global flag. Something like this > could be accomplished by using a custom attribute metaclass, which > would be easy to use through the Moose::Policy module. But right > now, I am concentrating efforts on making type constraints faster > instead. > Fair enough. I might try to put this in if I'm motivated enough, but I'll wait for your type constraint performance improvements first and wait for benchmarking to tell me that this is actually a bottleneck. I'm coming off three years at Amazon so it is likely that I'm overly and prematurely concerned about performance right now. :) >>> One alternative, which I use myself, is to downgrade to Moose >>> 0.11 (and Class::MOP 0.30 or so). It is still a little slow, but >>> much more manageable, especially if you are still in the >>> development phase where speed really shouldn't be that important. >> >> Cool - I'll try these out in the benchmark. > > Well they are faster, maybe by about a factor of 2, but that's > still pretty slow. However, it might be suitable enough for > development, and unless you have an extremely tight schedule, the > Moose speed boosts should be production ready by then. > > Keep in mind that Moose is not a hobby module for me, I use it in > production at $work on our core offering and it has the full > backing of the $boss as well. And now that current $project is > pretty much ready to launch, I should have much more tuits to put > towards this. That's really good to hear. To be honest, I was a little surprised at the lack of activity on this mailing list and at the generally tepid results from googling for Moose...I wasn't sure how active the project was. But I am encouraged by your comments and by the quick response on this list! Best, Jon