On 14 heinä, 05:57, 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) > > We could store which fields have these hooks upon ModelBase.__new__ > construction and so skip most fields and overhead in __init__. > > I'm happy to make a pull request but checking here to see if there's > any pushback.
A big +1 from me. Maybe the fields could explicitly add methods to pre/post init hooks in contribute_to_class instead of method autodiscovery? The signal receiver caching approach is another alternative (https:// code.djangoproject.com/ticket/16679). The downside of that approach is that it complicates the already complex signals framework, so for that reason it seems better to get rid of the post/pre init signals. - Anssi -- 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.
