[Melbourne-pm] New module: Number::Phone::AU

[Michael G Schwern]

On 2011.1.7 4:52 PM, Toby Wintermute wrote:
> On 7 January 2011 16:01, Michael G Schwern <schwern at pobox.com> wrote:
>> On 2011.1.7 2:45 PM, Toby Wintermute wrote:
>>> I use Moose everywhere, but don't want some random modules using Mouse
instead.
>>
>> I want to answer that in detail, because Mouse gets a lot of crap based on
>> outdated information.  I've been relying on Mouse extensively for
>> Test::Builder2 and it continues to amaze me how complete and fast it is.
>
> Really?
> I tried search-and-replacing all "use Moose" to "use Mouse" in one of
> my apps to try a comparison of total memory use in a large project,
> however with Mouse the project fails to fire up at all -- and I don't
> think I'm using Moose's features extensively.
>
>> 1) Mouse might be less feature complete.
>>
>> You'd be hard pressed to find a feature which is missing from Mouse at this
>> point.  And obviously Mouse has all the features needed for Number::Phone::AU.
>
> As above, it failed immediately; it looks like I need to mess around
> with some extra modules before Mouse supports attribute traits.

Mouse should support attribute traits.  I don't use them much myself, but the
Moose tests for them pass. *shrug*


>> 2) Moose + Mouse consumes more memory then just Moose.
>>
>> I measure it at about 1.5 megs more memory or just 10% of Moose.
Insignificant.
>
> But equally, does it matter if you just used Moose on its own? You
> would use less memory than both, and Moose's memory use, in a large
> project, is unlikely to be significant.

Hey, extra memory use was your argument. :)

It does matter.  Not everyone writes large, persistent projects where startup
time does not matter.  Yes, people write command line tools.  CPAN modules are
supposed to be flexible, and an object system should not restrain the
environments in which a module is useful.


>> There's no really compelling reason why some random module, which is a black
>> box, can't use Mouse.
>
> I just dislike having multiple implementations of the same protocol
> loaded; it seems messy to me.

Well, that's something you're going to have to work out with your therapist. ;)

The wonderful thing about modules is well written ones are black boxes.  If
you don't like messy details, don't look inside.


>> The second problem with Any::Moose is that Mouse is now significantly *faster*
>> at runtime than Moose.  This is likely the result of Mouse::XS.  Here's my
>> benchmarks adapting Ovid's from
>> http://blogs.perl.org/users/ovid/2010/01/roles-without-moose.html
>
> Mmm... so why couldn't the effort to speed up Mouse be put into Moose too?

Because of the extensible nature of Moose, I'd imagine it's harder to
optimize.  A higher barrier is likely the philosophical difference between the
two development teams.  The Moose folks are developing a meta object system
more than they're developing an OO system for Perl.  Their focus is on the
MOP.  They consider Moose to be just sugar.

For the Mouse team, Mouse is it.  There is no goal but to produce a light,
fast version of Moose.

And as they're two radically different code bases under the hood you can't
just port an optimization from one to the other.

That said, having Mouse is blow the doors of Moose might light a fire under
the Moose devs.

Either way, I have code I need to run now.


> (Aside: I am a little wary of the high-performance XS stuff that comes
> along; sure, they are fast, but things like Template::Stash::XS,
> Template::Alloy::XS and Class::XSAccessor have left a bad taste in my
> mouth with their bugs.)

This is what testing is for.  The Mouse::XS stuff goes through the same
extensive test suites as pure Perl Mouse.  They actually copy and modify the
Moose test suite.


>> Using Mouse is *faster* than a simple Perl accessor.  It's approaching raw
>> hash access.  Moose with a type check is 10x slower than raw hash access.
>>
>> So if you want performance, use Mouse use Moose.  This runs directly counter
>> to Any::Moose.
>
> Aren't we prematurely optimising here though?
> You're taking a module that has less features and less of a track
> record and is probably less stable, and choosing it because it's
> currently faster for stuff.. when that stuff might not actually be
> significant to your programs' performance at all.
> (Although OK, if its your accessors, it's quite likely it would help)

Since Mouse is a general purpose module that can be used in every environment,
yes optimizing getters in by an order of magnitude will definitely help
performance.  They're accessors, they don't do much and they get called a lot.
 I have more than once found getters to be a real performance hog.

Look at it another way: there is no longer an excuse to write objects by hand
or violate encapsulation by grabbing at the guts of an object "because it's
faster".


> Well, it does sound like Mouse is in a better state than I thought; I
> thought it had died off a bit once Moose had sped up a bit.
> Perhaps I can look into it and see if it makes a difference to
> projects I care about.

Yeah, when I talk about Mouse most folks say "wasn't that killed?"  There was
a point when they were going to, but then development picked up again.
Partially because I told Sartak I needed Mouse for Test::Builder2.  There's
been a bunch of new maintainers and the current guy has a lot of vigor.

There's also Matt Trout's "Moo" but I don't know what state that's in.


-- 
Defender of Lexical Encapsulation