[email protected]
[Top] [All Lists]

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

Subject: Re: [Qt4-preview-feedback] Qt 4.5 QMutex spin mechnism poor performance
From: "Bradley T. Hughes"
Date: Tue, 17 Feb 2009 09:20:09 +0100
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 

> 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 

> Many thanks and best regards,
> Martin Dyde,
> Milan Digital Audio LLC.
> http://www.crumhorn-labs.com/
> http://www.milandigitalaudio.com/

Bradley T. Hughes (Nokia-D-Qt/Oslo), bradley.hughes at nokia.com
Sandakervn. 116, P.O. Box 4332 Nydalen, 0402 Oslo, Norway
Qt4-preview-feedback mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>