[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
-~----------~----~----~----~------~----~------~--~---

Reply via email to