[EMAIL PROTECTED] wrote: > Matthew, would you mind sticking the script you used to test this up > on dpaste?
I'd love to, but it wasn't really a script per se, so much as a hodge- podge that involved twiddling the server, restarting it, running some tests, changing the server config again, and so forth. If I get a moment to tidy it up into something dpasteable I'll do so. Jacob Kaplan-Moss wrote: > <[EMAIL PROTECTED]> wrote: >> Okay, I decided to do a bit of profiling to keep the conversation >> moving. > I did too; I took a stab at measure the raw speed of calling signals. Sweet. To the limited extent that our tests are comparable, they appear to be in rough agreement. For example, they both show a signal with a single trivial listener costing about nine times as much as a signal with no listeners. Jacob Kaplan-Moss wrote: > Given that, I'm generally going to be -1 on adding any non-essential > signal to Django that's *connected by default* -- the overhead is too > much, so internal uses should just use plain old function calls. > However, I don't see that it's *too* bad to add a signal (like > connection-created) with no listeners... but we should be careful in > the documentation to clearly explain the substantial overhead > involved. Okay. Given all this, how do people feel about a connection_created signal? What about a cursor_created signal, either instead or in addition? (I have no use case for that, but if for some reason people prefer it to connection_created it will still be sufficient to solve my immediate problem.) Malcolm Tredinnick wrote: > A random thought: is there any other information worth sending along > with the signal? Right now, the receiver is told "a connection was > created". Anything that's likely to vary and that could be useful as a > trigger for other actions? I was thinking about this, too. Right now the most important thing is the type of database connection being created, which you can determine from the sender, and which you can determine from settings anyway. However, the big question in my mind is how all of this relates to the multiple-database support that folks seem to be working on. Does anyone from that camp want to chime in? Matt Matt Hancher Intelligent Systems Division NASA Ames Research Center [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---