Re: Moose speed and schedule

Jonathan,

On Nov 12, 2006, at 2:51 PM, Jonathan Swartz wrote:
> It's pretty simple - even the accessor declarations are superfluous  
> since I'm just calling constructors, though oddly if I take out the  
> 'has' declaration Moose gets a little slower.

I am not sure about why lack of attributes is actually slowing you  
down, I will try and reproduce that one. The issue is mostly in how  
we construct an instance. First we collect all attributes (local and  
inherited) and then build a meta-instance to construct the real  
instance. This is a time consuming process since nothing is cached at  
all. This is the benefit of the immutable version, it caches all  
these things, so they only need to be generated once at compile time.

>>> http://code2.0beta.co.uk/moose/svn/Moose/trunk/lib/Moose/Cookbook/ 
>>> FAQ.pod mentions that immutable classes may eliminate, or at  
>>> least vastly improve, object construction performance, and  
>>> implies this will hopefully be done by the end of the year. Does  
>>> this schedule still sound reasonable?
>>
>> There is currently an experimental branch of the immutable Moose
>>
>> http://code2.0beta.co.uk/moose/svn/Moose/branches/Moose-immutable/
>>
>> it requires this branch from Class-MOP as well
>>
>> http://code2.0beta.co.uk/moose/svn/Class-MOP/branches/Class-MOP- 
>> tranformations/
>>
>> It is not yet finished, but the plan is to get it completely  
>> working by the end of this month. Production worthiness will take  
>> a little longer of course, probably close to that "end of the  
>> year" timeline.
>>
>> Early benchmarks show an average performance boost of 400-500%,  
>> with a upper ceiling of 1200% for really simple constructors and a  
>> bottom of about 175% for very complex constructors. A lot of this  
>> is dependent upon the complexity of your attributes, and I do my  
>> best to make sure you only pay for what you actually use.
>>
>> This branch also includes a speed up version of the type  
>> constraint system as well, which shows a performance boost of  
>> around 400% from previous versions. This also contributes to the  
>> speedup in object construction as well.
>>
>
> 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.

>>> In the meantime, does anyone have a recommendation for an  
>>> alternate class framework I can use that will make the eventual  
>>> jump to Moose as painless as possible?
>>
>> Well, it all depends on what Moose features you use.
>
> We've just started out so it's hard to know which Moose features  
> we'd be using. The accessor and type declarations and default  
> constructors, of course - these are available elsewhere on CPAN but  
> I like Moose's syntax far better than others.

Well for these features, you can try David Wheeler's Class::Meta +  
Class::Meta::Express. As David points out in his reply, he and I have  
been planing a meeting of the MOPs sometime when we can each get the  
tuits. This should also take care of your class introspection needs  
as well.

> Before and after methods are nice too.

This is uniquely Moose right now, sorry.

> Hopefully any class introspection we end up doing will be "pay for  
> what you use" as you suggest.

> 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.

>> 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.

- Stevan