#16679: Speed up signals by caching the reveicers per sender
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.3
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 0
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
As I see it, your approach is the right one, at least as long as we don't
want to support inherited signals. There are some problems when trying to
make inherited signals work, though.
The problem for inherited signals is that at the time the signal is
registered, we don't necessarily know all of the sender's subclasses. And,
when a model is created by the apploading code, we don't know the signals
yet. So, we would need to update the signal datastructures when a new
signal is connected, disconnected or a new subclass is registered in the
app cache. In the two first cases, we should check all the subclasses of
the sender, and in the last case we would need to check the parents of the
sender.
My approach to that problem is that when a signal is sent, we cache the
found results. When a receiver is connected or disconnected we flush all
the caches. This would make it perhaps easier to support inherited
signals, as there is just one point when we need to check the parents and
cache the results based on that. On the other hand, my version is very bad
if you do dynamically connect / disconnect signals, as the caches would
get flushed all the time and the caching would just increase the overhead,
not reduce it. I don't know if dynamical connect is a common use case.
Of course, there is no decision if we actually do want to support
inherited signals. They would be useful, as one would usually want to have
`BaseModel` pre_save/post_save sent when `InheritedModel` is saved.
--
Ticket URL: <https://code.djangoproject.com/ticket/16679#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en.
