[Qt4-preview-feedback] Qt 4.5 QMutex spin mechnism poor performance

[Philippe]

Why don't you use in Qt "Critical Sections" (Windows and Mac). They work  
great and fast, and do the same as QMutex.

Philippe

On Tue, 17 Feb 2009 09:20:09 +0100, Bradley T. Hughes  
<bradley.hughes at nokia.com> wrote:

> Martin Dyde wrote:
>> Hello Qt team,
>> I'd been seeing a drop in performance when moving from Qt 4.4.3 to Qt  
>> 4.5, and I've tracked it down to a change implemented in Qt 4.5's  
>> QMutex::lock() fn, in which you've added a new 'mutex spinning'  
>> mechanism which repeatedly re-tries to get the lock from the OS, rather  
>> than just waiting on it.  This causes approximately a 25 percent drop  
>> in overall application performance (polyphony) in our case, i.e. a very  
>> significant and measurable degredation.
>
> Ouch... that's not good :/ All of my tests showed that the short spin  
> actually improved performance under contention, but obviously I can't  
> test everything. Are the mutexes in your application highly contented,  
> or mostly unused?
>
>> If I manually remove the new spin code from the Qt src, so that  
>> QMutex::lock() behaves the same as it did in Qt 4.4.3, then all is well  
>> again and we get that 25 percent of performance back.
>
> Would you consider trying to tune the constants to see if there's some  
> middle ground to be found? For example, what about:
>
>      enum { AdditionalSpins = 10, SpinCountPenalizationDivisor = 10 };
>
> ?
>
>> I appreciate that there might be some cases where the spinning  
>> mechanims could give improved performance, but for our type of  
>> application it's very definitely (and measurably) much worse.
>
> And a performance regression is definitely something we can't have...
>
>> Since we have a work-around for it (a custom edit to the Qt src to take  
>> out the spin functionality), it isn't a high priority for us, but my  
>> request would be for the longer term that you could make the spin  
>> functionality optional - perhaps a new QMutex property to avoid having  
>> the overhead of having to to pass an extra bool to QMutex::lock() or  
>> QMutexLocker with each call?  Or, probably better still, a  
>> precompiler/configure option to avoid the spin code (and also avoid a  
>> runtime condition) altogether?
>
> That we could do, but honestly I'd probably just end up removing the  
> spinning if it doesn't work the way it was intended (which was to  
> improve through-put for highly contended mutexes that are held for short  
> amounts of time).
>
>> Many thanks and best regards,
>>  Martin Dyde,
>> Milan Digital Audio LLC.
>> http://www.crumhorn-labs.com/
>> http://www.milandigitalaudio.com/
>>
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/