On 31/05/11 00:26, Alex Gaynor wrote:
> Hi all,
>
> I'm looking at r16297 (https://code.djangoproject.com/changeset/16297),
> and I don't like this approach, I understand what it is trying to
> accomplish, but it has several downsides that don't appear to have been
> considered:
>
> a) On CPython a class object is pretty large, and they are very easy to
> get into reference cycles that won't be collected for a while.
> b) On PyPy (and IronPython AFAIK, and *maybe* CPython) creating a new
> class for each instance can lead to poor performance because they
> prevent reusing various caches, or can cause overspecialization.
Thanks for pointing out these, I wasn't aware of these issues.
If we kept the pre-made request subclasses around in a cache and re-used
them, would it fix these problems? Something like:
---
_request_subclass_cache = {}
def add_user_property(request):
try:
SubClass = _request_subclass_cache[request.__class__]
except KeyError:
class SubClass(request.__class__):
user = LazyUser()
_request_subclass_cache[request.__class__] = SubClass
request.__class__ = SubClass
return request
----
Regards,
Luke
--
"The truth will set your teeth free." (Calvin and Hobbes)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
