As a simple short-term solution, why not cache calls to get_cache that don't pass additional arguments? That is, ones that only get pre-configured caches.
-- Curtis On 25 August 2013 23:26, Florian Apolloner <f.apollo...@gmail.com> wrote: > Hi, > > so when reviewing https://github.com/django/django/pull/1490/ I once > again ran over an issue with our current caching implementation: Namely > get_cache creates a new instance every time which is kind of suboptimal if > you don't store it as module level variable like we do with the default > cache. Are there any objections to make get_cache store those instances in > a dict and return those on request? It shouldn't cause to much problems, > since the current cache infrastructure expects you that you can share those > objects over multiple threads and requests anyways [And for caches which > don't support it like pylibmc we use threadlocals…]. Changing how get_cache > works could significantly reduce connections to the cache server depending > on how your views/templates are written. > > Thoughts? > > Cheers, > Florian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
