On Sat, Jul 14, 2012 at 10:57 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > I was poking around in our (Votizen's) use of signals and thinking > about making some tooling so that signal usage was a bit more > transparent. > > In doing so, I noticed that GenericForeignKey hooks the model pre_init > signal. It does that because GFK needs a chance to munge kwargs from > the GFK field name to the content_id and object_id fields. > > Signal dispatch with zero receivers is much much faster than with 1 or > more receivers, and pre_init is fired quite a lot. Pretty much every > decent sized project I've worked on has used GFK, so I imagine this is > a large sap on performance overall. > > Similarly, I just noticed that ImageField does a similar thing, > setting dimension values in post_init. > > I think we could get a significant performance win if, instead of > using pre_init/post_init here, we changed Model.__init__ to call a > per-field hook that could munge the Model.__init__ kwargs. > > SomeField.model_pre_init(instance, args, kwargs) > or maybe for symmetry with contribute_to_class: > SomeField.contribute_to_instance(instance, args, kwargs)
+1 to this idea. My only concern is: > We could store which fields have these hooks upon ModelBase.__new__ > construction and so skip most fields and overhead in __init__. I'm not sure if I'm misreading your intentions here, but just to be sure -- I'd like to avoid explicitly naming certain field types as "special" in ModelBase if at all possible. If we explicitly name certain fields in ModelBase, then it means that third-parties with the same requirement won't be able to exploit the same API entry point. In the case of GenericForeignKey specifically, it also means that we would be introducing a dependency (even if it was name-only) on contrib into core -- which is something we've been trying to move away from. Russ %-) -- 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.
