On Thu, Dec 20, 2007 at 10:45:24PM -0600, Jeremy Dunck wrote: > > On Jun 13, 2007 8:29 PM, Brian Harring <[EMAIL PROTECTED]> wrote: > ... > > Either way, I'm still playing locally, but I strongly suspect I'll > > wind up chucking the main core of dispatch.dispatcher and folding it > > into per signal handling; may not pan out, but at this point it seems > > the logical next step for where I'm at patch wise. > ... > > > Brian,
Helps to CC me, been crazy busy lately over the last few months and watching this ml less and less unfortunately. > Did anything come of this? I'm interested in several uses of > signals. At the Dec 1 sprint, Jacob said he'd prefer not to add any > signals until the performance issues are addressed. > I'm willing to work at improving the performance, but David > indicated that you may have something worth supplying back to django > trunk? Haven't gone any further on my signals work since #4561 is currently bitrotting- the intention was to basically shift the listener tracking all into individual signal objects; the basic machinery required is avail. in the patches posted on that ticket. Presuming folks liked the approach, the intended next step was to shift away from using django.dispatch.dispatcher.connect to bind a callable to a signal, to signal_inst.connect(func) as the default, gutting the remaining dispathcer internals, shifting it into the signal objects themselves. In the process, moving the robustapply bits up from checking everytime the signal fires, to checking when the connection is established- end result of that would be faster signaling, and reduction of a lot of the nastyness robustapply attempts at the point of signaling. Either way, #4561 is the guts of my intentions- resurrecting signals work starts at resurrecting that patch ;) If there is interest in getting this commited, I would like to know- that patch alone was another 25% speed up in model instantiation when no listener was connected for that model. One additional optimization point for signals is deciding whether connect(Any, f1) connect(Any, f2) Must execute f1, f2 in that explicit order- internally, dispatcher uses some nasty linear lookups that could be gutted if f1/f2 ordering can vary. Never got any real feedback on that one, so have left it alone. ~brian
pgpgKdp4SxzJG.pgp
Description: PGP signature
