On Mon, Mar 24, 2008 at 10:55:03PM -0500, Jeremy Dunck wrote: > One other enhancement I thought might be good is to have a > Model.pre_init signal
Such a signal exists already last I looked, same for post_init... Please clarify. > Other similar class-based > receiver lists might speed things up in some cases; the down-side is > that each receiver list has some overhead, even if empty. Please see ticket 4561... my attack of dispatch was to disable it when nothing was listening, dynamically re-enabling it when there was a listener. Via that, there is *zero* overhead for disconnected signal pathways- slight overhead addition when something is listening (specifically addition of another function call), but pretty much neglible. Suspect you and I came at it from different pathways; my plan was to target common optimization (model initialization, 25% boost when no listener connected), then work my way down. The next step I was intending, presuming that patch ever got commited, was to move actual connect/send directly into the signal instances including the arg checking; might I suggest merging functionality of the two? Literally, you're doing the second step I was after, while the first step levels a pretty significant gain for scenarios where signals aren't currently used. ~brian
pgpivunVoh9zI.pgp
Description: PGP signature
