#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: 1
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
The senders_no_receivers cache is there to make the sending marginally
faster. But I think if you did on the last line this:
{{{
return receivers and deref(receivers) or []
}}}
I would be actually as fast as the senders_no_receivers cache version, as
you would get rid of that function call. Other than that your code does
look much better.
The problem with not having .use_caching property is that if somebody
decides to use dynamic classes with the signaling system, you will get
really bad memory leak - every dynamic class will be stored in the cache.
This is not a problem with model classes, because you will leak the
classes anyways in app models cache.
So, what do you think, which way should we go here, caching, your version
or both?
The `Haystack` use case is following:
{{{
class NoteIndex(RealtimeSearchIndex):
# Index definition
site.register(Note, NoteIndex)
}}}
Because you use RealtimeSearchIndex, haystack will connect to the signals,
and do automatic updates of the index in the signals. Now, if you have
SpecialNote(Note) class, and you save a SpecialNote, you will NOT get the
index updated, even if you saved a note. Even a ProxyNote(Note) would
break your indexing. There are surely other use cases like that. For
example you could have an extension "django-audits", where you register an
audit_trail for a model, and it will automatically do auditing for you.
Now, if you use subclassing (even proxy classes), suddenly your auditing
is not there. See the problem?
Although there are other problems for signals, too: they are not sent when
you do qs.update, nor are they sent when you do bulk_create. I have some
ideas of how there could be fixed, although that would mean first fetching
the to-be-updated resultset in qs.update() and then doing the update in
one query. So it would mean that if you update a gazillion rows in one go,
you would get a LOT worse performance... But having data modification
signals that are only sometimes sent will lead to problems for users who
think they can audit their data by just signals. Ah well, getting out of
this ticket's topic again... :)
--
Ticket URL: <https://code.djangoproject.com/ticket/16679#comment:12>
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 django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
