Bug #78227 for CHI: Could it be redone without Moose?

Thu Jul 05 14:04:13 2012 dmuey [...] cpan.org - Ticket created

Subject:

Could it be redone without Moose?

I'd love to use this module, its a great idea, but it uses Moose which is really huge. If not I'll see about making a similar a mooseless version in a different NS.

Thu Jul 05 14:45:56 2012 JSWARTZ [...] cpan.org - Correspondence added

CHI gets a ton of benefits from Moose. I tried to use Mouse in an old version, but I kept running into missing or broken features. What do you mean by "really huge"? Do you mean amount of memory, or amount of disk space, or number of dependencies, or it just feels big conceptually? Are you on a hosting provider with a very restricted amount of memory/disk space? On Thu Jul 05 14:04:13 2012, DMUEY wrote: Show quoted text

> I'd love to use this module, its a great idea, but it uses Moose which > is really huge. > > If not I'll see about making a similar a mooseless version in a > different NS.

Thu Jul 05 14:45:56 2012 The RT System itself - Status changed from 'new' to 'open'

Thu Jul 05 15:16:16 2012 dmuey [...] cpan.org - Correspondence added

Show quoted text

> CHI gets a ton of benefits from Moose.

And let me assure you, I'm not trying to start a Moose war, I just love the concept of CHI (I enjoyed your talk @ YAPC about it BTW) and have seen the same basic idea implemented wonderfully without moose (e.g. Log::Dispatch) Show quoted text

> What do you mean by "really huge"? Do you mean amount of memory,

yes, process RSS goes up almost 12MB just using it from a quick and dirty check: [dmuey@multivac ~]$ perl -e 'print `ps u -p $$`;' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND dmuey 39922 0.0 0.0 2437344 1204 s000 R+ 1:46PM 0:00.04 perl -e print `ps u -p $$`; [dmuey@multivac ~]$ perl -MMoose -e 'print `ps u -p $$`;' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND dmuey 39928 46.9 0.2 2444940 13124 s000 R+ 1:46PM 0:00.35 perl -MMoose -e print `ps u -p $$`; [dmuey@multivac ~]$ by comparison Log::Dispatch, that I noted earlier as a similar concept but for logging instead of caching, only adds about 2 MB to RSS even with quite a dependency chain itself. Show quoted text

> or amount of disk space,

not so much that Show quoted text

> or number of dependencies,

maybe a bit: it takes time to find all of them and load them and compile them, for what benefit exactly? a few less lines of code and MOPiness? Doesn't seem worth it to me for an abstract caching mechanism Show quoted text

> or it just feels big conceptually?

I suppose that fits a little, MOP is cool, I get that, its a great idea. Just not when its cost outweighs the benefit. Show quoted text

> Are you on a hosting provider with a very restricted > amount of memory/disk space?

no, I just don't want my personal servers bogged down for no reason and our customers demand reasonable memory use, thus Moose is out the door along w/ Java :)

Thu Jul 05 16:34:54 2012 swartz [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date:	Thu, 5 Jul 2012 13:34:41 -0700
To:	bug-CHI [...] rt.cpan.org
From:	Jonathan Swartz <swartz [...] pobox.com>

On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: Show quoted text

> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > >

>> CHI gets a ton of benefits from Moose.

> > And let me assure you, I'm not trying to start a Moose war, I just love the concept of CHI (I enjoyed your talk @ > YAPC about it BTW) and have seen the same basic idea implemented wonderfully without moose (e.g. > Log::Dispatch) >

Log::Dispatch was written long, long before Moose. I guarantee that Dave would not consider it wonderful today and that he would use Moose if he created it now. :) Show quoted text

>> What do you mean by "really huge"? Do you mean amount of memory,

> > yes, process RSS goes up almost 12MB just using it from a quick and dirty check: >

Ok, that helps quantify it. 12 MB is "big" when compared to raw Perl I suppose, but miniscule when considering amounts of memory on modern systems. Show quoted text

>

>> or number of dependencies,

> > maybe a bit: it takes time to find all of them and load them and compile them

about 1 minute on my system Show quoted text

> for what benefit exactly? a few less > lines of code and MOPiness? Doesn't seem worth it to me for an abstract caching mechanism

It is very much worth it, assuming that you don't consider 12 MB a significant cost on any modern system, which I don't. An incomplete list of benefits off the top of my head: * Default attribute values and lazily built attributes * Type checked attributes and type coercion * Strict constructor (dies if bad key is passed - not in CHI currently but will be shortly) * Optimized constructors * Roles, for things like size awareness and subcaches * Method modifiers, e.g. before, after, around You can see evidence of the first three in the first 50 lines of CHI/Driver.pm. For the last two see http://www.openswartz.com/2009/06/01/how-roles-pushed-me-over-to-the-moose-side/ Yes, it is possible to do all this without Moose, of course. Just a ton more code, tedium, testing, reinventing the wheel. I am living this now with Code::TidyAll (https://metacpan.org/module/tidyall), which I wrote without Moose because the common case is using a command-line script and I am sensitive to Moose's startup cost for this particular case. I am really missing Moose in the development of even this much smaller distribution, and if/when Moose startup time improves as it almost certainly will in the future (they are planning to embed the MOP into Perl), I will move this to Moose right away. Show quoted text

>> Are you on a hosting provider with a very restricted >> amount of memory/disk space?

> > no, I just don't want my personal servers bogged down for no reason and our customers demand reasonable > memory use, thus Moose is out the door along w/ Java :)

I'm shocked that 12 MB per process makes a difference, especially if you are using a web or other pre-forked app in which most of this would be shared memory. Does it really matter to your customers? Or is it mostly psychological/principle? Of course, you are free to write CHI::NoMoose or whatever. Just keep in mind the time/money trade-off and ask yourself how much it would cost to add a GB or whatever to your server instead. HTH, Jon

Thu Jul 05 17:27:39 2012 dmuey [...] cpan.org - Correspondence added

ok, thanks for your time and quick response.

Thu Jul 05 17:27:40 2012 dmuey [...] cpan.org - Status changed from 'open' to 'rejected'

Fri Jul 27 14:12:31 2012 http://dmaestro12.myopenid.com/ - Correspondence added

From:

dmaestro

On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote: Show quoted text

> > On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: >

> > Queue: CHI > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >

> >> CHI gets a ton of benefits from Moose.

> > > > And let me assure you, I'm not trying to start a Moose war, I just

> love the concept of CHI (I enjoyed your talk @

> > YAPC about it BTW) ...

I echo Daniel's comments, especially those quoted above. With the recent buzz about Moo, [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-is-in.html] I wonder if you would consider moving in that direction? What benefits does Moose provide that Moo doesn't and that prevent doing that implementation easily? (Wish I had more experience with both, I'd answer that question myself!) I am in a position where it will be some time before my company can migrate key applications to Moose (much as I would like to). And until MOP is in the core, I really would like to have the option of moving caching to CHI in the meantime. With the full Moose dependency, I simply don't. DLS

Fri Jul 27 14:12:32 2012 The RT System itself - Status changed from 'rejected' to 'open'

Fri Jul 27 18:23:56 2012 swartz [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date:	Fri, 27 Jul 2012 15:23:35 -0700
To:	bug-CHI [...] rt.cpan.org
From:	Jonathan Swartz <swartz [...] pobox.com>

On Jul 27, 2012, at 11:12 AM, http://dmaestro12.myopenid.com/ via RT wrote: Show quoted text

> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote:

>> >> On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: >>

>>> Queue: CHI >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > >>>

>>>> CHI gets a ton of benefits from Moose.

>>> >>> And let me assure you, I'm not trying to start a Moose war, I just

>> love the concept of CHI (I enjoyed your talk @

>>> YAPC about it BTW) ...

> > I echo Daniel's comments, especially those quoted above. > > With the recent buzz about Moo, > [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-is-in.html] > I wonder if you would consider moving in that direction? What benefits > does Moose provide that Moo doesn't and that prevent doing that > implementation easily? > > (Wish I had more experience with both, I'd answer that question myself!) > > I am in a position where it will be some time before my company can > migrate key applications to Moose (much as I would like to). And until > MOP is in the core, I really would like to have the option of moving > caching to CHI in the meantime. With the full Moose dependency, I simply > don't.

Moo is certainly more likely than plain-old-objects, I'll consider it. I'd have to think about the feature gap. Likewise, can I ask what is preventing your company from using Moose? Is it memory usage? Startup time?

Mon Jul 30 07:46:22 2012 http://dmaestro12.myopenid.com/ - Correspondence added

From:

dmaestro

On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote: Show quoted text

> > On Jul 27, 2012, at 11:12 AM, http://dmaestro12.myopenid.com/ via RT > wrote: >

> > Queue: CHI > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > > > On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote:

> >> > >> On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: > >>

> >>> Queue: CHI > >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >>>

> >>>> CHI gets a ton of benefits from Moose.

> >>> > >>> And let me assure you, I'm not trying to start a Moose war, I just

> >> love the concept of CHI (I enjoyed your talk @

> >>> YAPC about it BTW) ...

> > > > I echo Daniel's comments, especially those quoted above. > > > > With the recent buzz about Moo, > > [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-

> is-in.html]

> > I wonder if you would consider moving in that direction? What

> benefits

> > does Moose provide that Moo doesn't and that prevent doing that > > implementation easily? > > > > (Wish I had more experience with both, I'd answer that question

> myself!)

> > > > I am in a position where it will be some time before my company can > > migrate key applications to Moose (much as I would like to). And

> until

> > MOP is in the core, I really would like to have the option of moving > > caching to CHI in the meantime. With the full Moose dependency, I

> simply

> > don't.

> > Moo is certainly more likely than plain-old-objects, I'll consider it. > I'd have to think about the feature gap. > > Likewise, can I ask what is preventing your company from using Moose? > Is it memory usage? Startup time? >

We have a large, very important legacy application written about 8 years ago. I am still in the process of refactoring parts of it for maintainability. Although I would love it if I could replace all of the plain perl-OO with Moose, other priorities (like just moving from perl 5.8 to 5.10+) are higher. For new projects, the Moose dependencies would not be a problem. This is not a performance issue for me. It is entirely a maintenance issue. The work I am doing now will (I hope in the near future!) open the doors for using Modern Perl more extensively. I did look a little more closely at what the Moose dependencies are, and they are lighter than I thought, even though Moose itself is quite large. Thanks for the willingness to at least consider this! DLS

Sat Sep 15 13:35:25 2012 duvny [...] yopmail.com - Correspondence added

From:

duvny [...] yopmail.com

On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote: Show quoted text

>

Show quoted text

> Moo is certainly more likely than plain-old-objects, I'll consider it. > I'd have to think about the feature gap.

Also echoing support for $Moo++; $Moose--

Mon Sep 17 13:57:42 2012 swartz [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date:	Mon, 17 Sep 2012 10:57:31 -0700
To:	bug-CHI [...] rt.cpan.org
From:	Jonathan Swartz <swartz [...] pobox.com>

DuvNY: Reason? Memory usage, startup time, or number of dependencies? :) On Sep 15, 2012, at 10:35 AM, DuvNY via RT wrote: Show quoted text

> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote:

>>

>

>> Moo is certainly more likely than plain-old-objects, I'll consider it. >> I'd have to think about the feature gap.

> > Also echoing support for $Moo++; $Moose--

Thu Feb 28 22:12:43 2013 haarg [...] haarg.org - Correspondence added

I have a work in progress port of CHI to Moo. I have it passing all of its tests, and all of dependent CPAN modules still work with no changes. I still have a bit of cleanup I'd like to do, and I'd like to get some people testing it in the real world, but everything is looking pretty good so far.

Fri Mar 01 13:07:00 2013 JSWARTZ [...] cpan.org - Correspondence added

Great to hear! Given the backward compatibility I'm in favor. On Thu Feb 28 22:12:43 2013, haarg wrote: Show quoted text

> I have a work in progress port of CHI to Moo. I have it passing all of > its tests, and all of dependent CPAN modules still work with no changes. > > I still have a bit of cleanup I'd like to do, and I'd like to get some > people testing it in the real world, but everything is looking pretty > good so far.

Fri Mar 01 15:54:03 2013 webmaster [...] simplemood.com - Correspondence added

Subject:	Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date:	Fri, 01 Mar 2013 12:53:46 -0800
To:	bug-CHI [...] rt.cpan.org,Graham Knop via RT <bug-CHI [...] rt.cpan.org>,dmuey [...] cpan.org
From:	Dan Muey <webmaster [...] simplemood.com>

Woot! Graham Knop via RT <bug-CHI@rt.cpan.org> wrote: Show quoted text

><URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >I have a work in progress port of CHI to Moo. I have it passing all of >its tests, and all of dependent CPAN modules still work with no >changes. > >I still have a bit of cleanup I'd like to do, and I'd like to get some >people testing it in the real world, but everything is looking pretty >good so far.

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Mon Jun 24 17:25:22 2013 haarg [...] haarg.org - Correspondence added

I have the Moo conversion of this ready to release, however it suffers from a bug in Moo. I have a fix for that issue and am working on getting a new Moo release out soon.

Mon Jun 24 17:35:45 2013 dmuey [...] cpan.org - Correspondence added

Huzzah! On Mon Jun 24 17:25:22 2013, haarg wrote: Show quoted text

> I have the Moo conversion of this ready to release, however it suffers > from a bug in Moo. I have a fix for that issue and am working on > getting a new Moo release out soon.

Tue Jul 16 14:58:16 2013 blue [...] thisisnotmyrealemail.com - Correspondence added

From:

blue [...] thisisnotmyrealemail.com

On Mon Jun 24 17:35:45 2013, DMUEY wrote: Show quoted text

> Huzzah!

If it's ready, why not ship a trial version for the cpan testers to smoke? Show quoted text

> On Mon Jun 24 17:25:22 2013, haarg wrote:

> > I have the Moo conversion of this ready to release, however it suffers > > from a bug in Moo. I have a fix for that issue and am working on > > getting a new Moo release out soon.

Fri Jul 25 11:48:04 2014 deven [...] ties.org - Correspondence added

On Mon Jun 24 17:25:22 2013, haarg wrote: Show quoted text

> I have the Moo conversion of this ready to release, however it suffers > from a bug in Moo. I have a fix for that issue and am working on > getting a new Moo release out soon.

It looks like CHI now uses Moo as of Monday. Shouldn't this ticket be closed now?

Sat Jul 26 20:05:42 2014 JSWARTZ [...] cpan.org - Correspondence added

Right you are. CHI uses Moo as of 0.58

Sat Jul 26 20:05:43 2014 JSWARTZ [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jul 28 08:05:27 2014 dmuey [...] cpan.org - Correspondence added

On Sat Jul 26 20:05:42 2014, JSWARTZ wrote: Show quoted text

> Right you are. CHI uses Moo as of 0.58

Awesome, thank you!