in reply to Re: How to put a fat program on a (memory) weight-loss diet?
in thread How to put a fat program on a (memory) weight-loss diet? [SOLVED]

When I run Devel::Leak::Object, I am presented with a modest list of objects, mostly in Class::MOP and Moose::Meta, none of which (to me...) appear “particularly remarkable.” In fact, all of them appear to be associated with CPAN modules of quite-reasonable provenance and reputation.

I am rather pressed to believe, at this point, that this application is simply “a little bit too-big for the space that it's got to fit into.” And, perhaps, through no real fault of its own. (Which is not necessarily the verdict that I would have preferred to hear, of course.)

Replies are listed 'Best First'.
Re^3: How to put a fat program on a (memory) weight-loss diet?
by stvn (Monsignor) on Mar 05, 2009 at 19:07 UTC

    Those objects shown as "leaks" are your Moose metaclass instances which need to live for the entire life of your program, so they really aren't leaks. You might want to give Devel::Events a look, it is a much more fine grained leak checker. And lastly, yeah sounds like your program is just to big for the shared host environment.

    -stvn
Re^3: How to put a fat program on a (memory) weight-loss diet?
by Anonymous Monk on Mar 05, 2009 at 21:50 UTC

    Re-write your classes using hash-based objects rather than Moose. You'll have to generate your own method subs, but none of the program logic will need to change much.

    They'll take 1/10th the space and run 3 to 5 times more quickly.

      1. Moose objects are hash based objects, that won't change anything
      2. Depending on the actual classes (how many methods it has and how many attributes it has) it would be WAY more savings then 1/10th the size :)
      3. It may or may not run any quicker, Moose is pretty fast at runtime and vanilla Moose accessors typically benchmark pretty close to typical hand coded accessors (sure you can micro-optimize, but you loose readability/maintainability)

      The Moose "bloat" is coming from the metaclass instances, it is hard to reduce this because of two factors.

      1. That is what gives Moose all it's power
      2. Perl does not return memory to the OS, even if you DESTROY all your objects

      -stvn