Ticket #6814 is working to improve signal performance.
Feature tradeoffs:

Strong/weak receiver connections - strong-only is a big win-- about 2x
performance.  Any receivers going out of scope (and not to be called)
should be explicitly disconnected if we remove support for weak
receivers.

.send API enforcement - about a 20% overhead to ensure signals are
sent properly.  Worth it?

API whittling for extensibility: Leo has correctly pointed out that
**kwargs can be used for the same purpose.  Functions that accept
kwargs are fast-pathed, but maybe we should change to passing all
receiver arguments with kwargs to avoid the overhead entirely?
   kwargs vs whittling:  20% overhead to match APIs

In general, the latest patch optimizes for .send at the expense of
extra overhead in .connect and .disconnect.  .connect and .disconnect
are O(n) on number of active receivers for that signal; I don't
anticipate that being a big problem, though.

One other enhancement I thought might be good is to have a
Model.pre_init signal, similar to Model.DoesNotExist so that
.connect(class=Model, ...) would allow listening to, say, pre_init
only for instantiation of that model.    Other similar class-based
receiver lists might speed things up in some cases; the down-side is
that each receiver list has some overhead, even if empty.

Please see the ticket for timings and alternate implementations.

Regardless of the outcome, the patch also adds regression tests for
signals which I believe would be useful.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to