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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
