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

[Philippe]

I have ported a complex multitasked application to Qt, and I have replaced  
all Critical Sections with Qt mutextes. This works, no bug, but with a  
decrease of performance under stressed situations. This is why I do say  
QMutex could use the native critical section API as implementation.

Philippe

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

> Philippe wrote:
>> Why don't you use in Qt "Critical Sections" (Windows and Mac). They  
>> work great and fast, and do the same as QMutex.
>
> Qt doesn't have a critical section object, only 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/