On 13 April 2011 06:42, will trillich <[email protected]> wrote: > Mostly thinking out loud here... but we welcome feedback if we're off > track... > Okay, after some perl -D:NTYProf tester.pl with 200 iterations: > 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.) > > Most of the data won't change rapidly -- e.g. client lists, countries, > employees just to populate a few popup menus -- so it seems like an > opportunity to benefit from caching the results, and only invalidating the > cache when a new record gets updated/deleted/added. Whole tables could be > cached without having to return to SQL/DBIC for every form-screen. > So we're looking for documentation on a best-of-breed approach for doing > this in a Catalyst environment...
What might help you there is a H::FH field attribute "do_not_reload => 1". _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
