On Wed, Nov 21, 2007 at 02:42:11PM +0300, Oleg Pronin wrote:
> Unfortunately, it's too slow for production use.
The production users beg to differ.
DBIx::Class::Cursor::Cached is designed specifically to cache data in order
to deal with a situation where your primary constraint is the time the
query takes on the database.
If object construction overhead is also a problem, then obviously you need
a different approach - at that stage I'd look at keeping the objects
themselves around in memory since if construction is an important overhead,
revivication of the object graph from a cache is often pretty suboptimal
as well.
Caching is just another form of performance optimisation - you use it to
deal with bottlenecks. If a particular stage isn't a bottleneck, it's
irrelevant whether the cache bypasses that stage or not :)
--
Matt S Trout Catalyst and DBIx::Class consulting and support -
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Christmas fun in collectable card game form -
http://www.shadowcat.co.uk/resources/2007_trading/
_______________________________________________
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/
