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

[Nicholas Wehr]

>From what I recall - the caching trait doesn't play with joins. From what I
can tell - neither does H::FH; Can anyone confirm this? It might make more
sense for your queries to always specify a deep join/prefetch option to
reduce the number of queries.

I see this statement as well:

> "This feature is new. It doesn't handle relationships yet, and the
> interfaces are still subject to change."

... which leads me to believe that efficient joins aren't implemented

http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/Fo=
rmHandler/TraitFor/DBICFields.pm

<http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/F=
ormHandler/TraitFor/DBICFields.pm>
cheers,
-nw

On Thu, Apr 14, 2011 at 10:53 AM, Hernan Lopes <hernanlopes at gmail.com>wrote:

> i remember you mentioned something about many to many select options, try
> disabling those.. and then does the form works faster?
> if so, then the problem is mostly like in there ... try populating your
> options manually
>
> On Thu, Apr 14, 2011 at 1:15 PM, will trillich <
> will.trillich at serensoft.com> wrote:
>
>> On Wed, Apr 13, 2011 at 1:19 AM, Darren Duncan <darren at darrenduncan.net>=
wrote:
>>
>> 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.
>>>> (The 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 Dun=
can
>>
>>
>> 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!
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110414/42a22=
aa3/attachment.htm