Front page | perl.perl5.porters |
Postings from March 2011
On Sat, Mar 5, 2011 at 12:41, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
> Of course you might be wondering "well, what's wrong with that?" - the
> wrong starts the moment you leave the web-dev echo-chamber. The liberal
> (ab)use of *runtime* types actively encouraged by Moose more or less
> guarantees that your data will be examined N times in an identical way when
> traversing your lovely stack of neatly connected CPAN pieces. No matter how
> fast is your choice of iron, N checks will always suck N times more.
Moose rarely (unless you use certain MooseX::* modules) incurs
"runtime" type checking. It does type checking at object
*construction* time, but that type checking is usually fast enough for
any program you care to write. Here's a benchmark to back that up:
https://gist.github.com/858378
As you can see Moose is able to construct 180k objects per second
v.s. around 350k objects for a similar pure-Perl class. However if you
don't inline the object constructor Moose does 14k/s.
But for *accessing* the data Moose was actually faster than my first
stab at writing an accessor, meaning that in most code normal
programmers write Moose would speed up your code at the expense of
slightly more memory use. This is also what the Catalyst folks found
IIRC when they switched to Moose, I suggest you read up on that.
> in my line of work it in fact *never* is
I don't know what kind of work you do, but I very much doubt that
you're unable to spare 5-10MB extra ram for Mouse or Moose.
Particularly since Moose is not an all-or-nothing thing. I've written
programs where 95% of the program used boilerplate Moose code but in
one specific hot code path I wrote a pure-Perl class instead.
Thread Previous
|
Thread Next