[Dbix-class] memory usage to load schema

[Rob Kinyon]

On Wed, Feb 3, 2010 at 09:55, Bernhard Graf <dbic4 at augensalat.de> wrote:
>> This is not excessive in the slightest. Try this: create a duplicate
>> of each table Foo called FooCopy. So, you have 56 tables. Now, see how
>> much memory is used. I'll bet it's around 16MB.
>
> How comes?

"How comes"(sic) -what-??

> And how much can we rely on what (g)top or any other system monitor
> tells us about memory usage?

Uhh ... go ask your sysadmin.

> When I define my DBIC result classes, then I very often use the same
> column definition.
>
> Would I save something (besides typing and disk space), if I'd write:
>
>  package DBIC::Type;
>  use constant {
>    varchar_255 => {
>      data_type => 'varchar',
>      is_nullable => 1,
>      size => '255',
>    },
>    ... more common column definitions here ...
>  };
>
>  package MyApp::Schema::Result::SomeTable;
>  use DBIC::Type;
>  ...
>  __PACKAGE__->add_columns(
>    ...
>    firstname => DBIC::Type::varchar_255,
>    lastname => DBIC::Type::varchar_255,
>    address => DBIC::Type::varchar_255,
>    ...
>  );
>
> ?
>
> Looks even DRYer, btw.

It is and this is the reason I'm working on a way to have DBIC handle
user-defined types in a sane fashion.

However, I have to ask you a question - do you have to pay someone per
kilobyte of RAM used? Because, if you do, then Perl is **NOT** the
right language for you to be using. Perl is extremely profligate with
RAM usage and this is something that is well-documented in the core
and has been loudly shouted from the rooftops.

Perl is all about developer productivity at the cost (if there is one)
of RAM usage. If this is a problem, then you're using the wrong tool.

Rob