[Catalyst] Caching SQL results for speed...?

[will trillich]

On Wed, Apr 13, 2011 at 1:19 AM, Darren Duncan <darren at darrenduncan.net>wro=
te:

> will trillich wrote:
>
>> 70% of the time is taken up in five modules:
>> 1) SQL::Abstract
>> 2) DBIx::Class::ResultSet
>> 3) Class::Accessor::Grouped
>> 4) DBIx::Class::Storage::DBI
>> 5) HTML::FormHandler::Field
>> ...because in 200 iterations they were called millions of times each. (T=
he
>> form requested has several select/option menus.)
>>
>
> So, several 5000s (millions / 200) of calls for a single screen?  That
> sounds like a lot for one screen.  Do you need that much? -- Darren Duncan
>

My question is similar -- why five thousand or more calls for rendering one
page? The code does simple things like
my $form =3D $self->form;
# parse_form_for_numerics():
# change any $1,234 to 1234, parse 12-apr-09 to a date 2009-04-12, etc
# and stuff results into $c->req->params
&parse_form_for_numerics( $c, $form );
my $processed =3D $form->process(
  item =3D> $item,
  params =3D> $c->req->params,
);
if ( $form->has_errors) { ... }
return unless $processed;
# since we're testing rendering a fresh page there's no processing, that's
it

So why would this simple code generate 5,000+ calls to SQL::Abstract methods
or to DBIx::Class::Resultset methods? Even commenting-out
#parse_form_for_numerics()
it's about the same. Still looking into this.

-- =

11 cheers for binary!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110414/c53eb=
4e9/attachment.htm