[PyQt] Re: Serious performance problem with sipQtFindConnection

[Phil Thompson]

On Monday 17 September 2007, Giovanni Bajo wrote:
> Hi Phil,
>
> after some days/weeks of debugging/profiling some code without really
> getting any clue at the Python level, I tried oprofile on the code, and
> was shocked by sipQtFindConnection being shown as top entry (50% of the
> total time spent in that execution, with total execution time being 32
> seconds on my PC; so it's about 16 seconds spent in that function only).
>
> By doing some further research, it looks like the offending call is in
> sipWrapper_clear() (called from sipWrapper_dealloc()). For each SIP
> object destroyed, sipQtFindConnection is invoked, and it goes through a
> linear search of all connections.
>
> Since I have many small objects wrapped with SIP (which I allocate and
> deallocate galore), I can see this taking a lot of time.
>
> I am a little concerned because the code I'm profiling isn't Qt-related
> at all: it uses my own SIP objects, but not Qt. sipQtFindConnection
> seems more a bridge between SIP and Qt signal/slot, and it's a pity that
> all SIP objects in a program must pay this penalty (even those not
> related to Qt at all).
>
> I was wondering if something could be done in this regard. I can help
> with the coding leg-work, but I need some inputs as what can be tried to
> fix this.
>
> Thanks in advance!

The code is checking to see if any of the instance's methods are currently 
connected as a slot. This can apply to any wrapped class, including non-Qt 
ones.

Can you instrument the code in qobject.sip to count the different calls 
to "new PyQtProxy()" - there are 3 different places I think. Then display the 
3 counts when things start to go wrong.

One possible solution would be to keep the proxy instances used as slots in a 
separate list - but only if that count is low.

Another solution would be to maintain a flag in the sipWrapper that is set if 
the instance might have a connected method and only search if the flag is 
set.

Obviously there are other solutions, but the counts should point us in the 
right direction.

Phil